Trac in a corporate environment

As part of our move to Subversion we have also moved to Trac for issue tracking.

We had a home grown system which had certainly grown, by the time it was killed last week it had twenty five fields per reported issue! Few people understood the purpose of more than half of them. Worse still some of the options for these fields were incomprehensible. Each field had been added with good intentions but it all got out of hand.

Last Wednesday we transferred all issues from our system to Trac. When we planned this I fought tooth and nail to keep it simple. In the end we added four fields to standard Trac leaving us with a total of thirteen fields.

So what did we add? Here is the list:

  • Checkbox - 'Implemented' which is ticked when the code to fix a ticket is written but not yet reviewed or tested properly.
  • Checkbox - 'Implementation Reviewed' which is ticked when the code has been peer reviewed.
  • Checkbox - 'Tested' which is ticked when tests have been done. If this fault was reported by QA then they have to tick this when they are happy with the solution.
  • Textfield - 'Tests' which is a description of the tests which should be or have been done.

Once all the checkboxes are ticked the ticket can be closed. If the ticket is for a trivial item a comment can be added to indicate that tests etc., are not required.

We have also carefully defined the meanings of the options for the standard type and priority fields so there is no confusion over the impact of a ticket on the product(s) in question.

There is also a rule that commits and tickets should be cross referenced. I think we now have a system which will serve us well in keeping comprehensive records of faults, enhancements, and code changes which are simple enough for everyone to understand.

Thu, 2006-10-12 08:11
( categories: )