7.3. Software Engineering

Yoyodyne's software developers use RT to track defects and tasks related to their rocket control software. RT makes it easy for developers to track open issues and to dig for historical information about issues that were resolved ages ago. Any developer can open a ticket for a bug or task that needs to be handled. Development managers generally are responsible for assigning tickets to individual developers, but developers are encouraged to take responsibility for issues themselves when they have a bit of time on their hands and see something that they know how to handle.

Yoyodyne's RT administrators have hooked RT to their software version control system to let programmers update tickets as they check source code into the version control system. If you use Subversion, you can do the same thing using the RT-Integration-SVN package, which is available from your neighborhood CPAN mirror.

7.3.1. Custom Fields

The Software Engineering department uses custom fields more heavily than any other department within Yoyodyne. Custom fields make it easy for them to mark which product a given ticket applies to and what versions of the product are affected. When Yoyodyne's tech writers are preparing errata and release notes, the additional categorization provided by the custom fields makes it easy to find out what changed between two releases.

Platform

This SelectMultiple field lets engineers flag whether a particular task or issue applies to all platforms or just Linux, Solaris, Win32, or VMS.

Severity

This SelectSingle field tracks the severity of a bug. In descending order of severity, the values Yoyodyne uses are:

Wishlist

This ticket is a feature request or a bug that's from another dimension and will never be fixed.

Trivial

This ticket is a bug report for something relatively unimportant that's not going to get in anybody's way.

Normal

This ticket is a bug report. It's clearly a software defect, but isn't such a big deal that it's going to delay a release or cause anyone serious trouble.

Serious

This ticket is a bug report for something that causes the product to break but that can be worked around by an end-user without extraordinary measures.

Showstopper

This ticket is a bug that's so severe that the product can't be released. The bug either causes data loss or the product breaks during normal, common operations.

Product

Yoyodyne makes several different products. This SelectSingle field lets engineers tag whether a ticket refers to their Rocket Guidance Software, Mission Control Console, or Advanced Targeting Platform.

Broken In

This FreeformMultiple field lets developers manually key in the version numbers of releases that a bug is known to exist in, one per line. For tickets that aren't bugs, this field is left empty. Future releases of RT may enable this field to become a cascading field, one that is automatically populated with the correct list of version numbers corresponding to the value in the Product field.

Target Release

Every bug or task is assigned a Target Release. This FreeformSingle field tracks the version number of the release this ticket is expected to handle.

7.3.2. Groups

The Software Engineering team has a single group, Software Engineering, to define both the access control for their queue and the list of people who should get mail when someone updates a ticket. Everyone on the team is a member of this group. Yoyodyne's RT administrators added this group as an AdminCc for the Software Engineering queue, so that everyone can get mail about every ticket update using only standard scrips.

7.3.3. Scrips

Yoyodyne's developers are all email junkies. Most of their interaction with RT is via the email gateway. When a manager assigns a bug to a given developer, the developer usually does a bit of exploratory work to figure out what it will take to fix the bug and updates the ticket by email. Then RT automatically will distribute that mail to the entire development team for comment. When a developer checks in new code, the version control system integration sends out a ticket update to the entire development team with details of the check-in. The scrips for the Software Engineering queue shown in Table 7-3 are designed to make this process as simple and transparent as possible.

Table 7-3. Software Engineering scrips

Condition	Action	Template
On Create	Autoreply to Requestors	Autoreply
On Create	Notify AdminCcs	Admin Correspondence
On Correspond	Notify AdminCcs	Admin Correspondence
On Comment	Notify AdminCcs	Admin Comment
On Owner Change	Notify Owner	Transaction

The first scrip ensures that when someone enters a new bug or task into the Software Engineering queue, they get an acknowledgement by email. The second and third scrips make sure that all the mail about a particular issue gets sent to all of the queue's AdminCcs. Yoyodyne's engineers don't use comments much inside RT, but the fourth scrip makes sure that everyone gets notified when someone accidentally enters one. The last scrip makes sure that the developer knows that he's been assigned a bug or task.

7.3.4. ACLs

All software engineers have the same rights within the Software Engineering queue. Yoyodyne's RT administrators have granted the Software Engineering group the following rights for this queue:

     ShowTicket     ShowTicketComments     ShowOutgoingEmail     Watch     WatchAsAdminCc     CreateTicket     CommentOnTicket     OwnTicket     ModifyTicket     DeleteTicket     TakeTicket     StealTicket