Trac Ticket Workflow

Trac is the wiki and issue tracking system that is the most used for my software development projects. Let me share few hints about its ticket workflow, especially about the statuses, the roles of the participants, and let me give an example of the workflow config. But if you are interested in other things like Trac plugins, source browser, customizing, etc, let me know.

All the information given below regards the workflow described at the end of the article. The original Trac workflow is missed vital features like the support for ticket verifying, or the required ticket statuses range, so I do not use it in my projects.


The description of the main statuses:
  • new - the ticket has been created;
  • in-progress - the developer has began to work with the ticket;
  • fixed - the ticket is fixed (the problem issued in the ticket is solved);
  • verified - the ticket is verified (tester or PM has verified that the ticket is fixed correctly);
  • closed - the ticket is closed (it's not required to care about the ticket more).
Testers/PM have to do either of these things:
  • add comments for the ticket (with some clarifications, explanations, etc);
  • return the ticket into the work (via "ticket need to be re-worked" option) if they see that the bug/problem have not been fixed correctly;
  • verify that the ticket is fixed correctly (via "mark as verified" option);
  • create a new ticket with suitable description.
If testers/PM return the ticket into the work, they should add some comments to help the developers understand that they has done incorrectly.

Developers have to do either of these things:
  • accept the ticket for fixing (in that ways others can see on which tickets the developer works on);
  • set a suitable status for the ticket (fixed if it has been fixed, invalid if there are some problems preventing from the ticket been fixed, etc);
  • reassign ticket to other participants (for example, to other developer who is responsible for the problem issued in the ticket).
There can be other roles and actions, but it is not strict, and can vary in different cases. You can create your own workflow, which can be more suitable for your company or for the way you prefer to work.

In conclusion, let me give an example of the Trac ticket workflow (it should be specified in the trac.ini file):

[ticket-workflow]
accept = new -> in-progress
accept.name = accept ticket
accept.operations = set_owner_to_self
accept.permissions = TICKET_MODIFY
leave = * -> *
leave.default = 1
leave.operations = leave_status
reassign = new, in-progress -> new
reassign.operations = set_owner
reassign.permissions = TICKET_MODIFY
reopen = closed -> new
reopen.operations = del_resolution
reopen.permissions = TICKET_CREATE
resolve1 = fixed, verified -> closed
resolve1.name = resolve
resolve1.operations = set_resolution
resolve1.permissions = TICKET_MODIFY
resolve1.set_resolution = Done, Invalid, Duplicate
resolve2 = new -> closed
resolve2.name = resolve
resolve2.operations = set_resolution
resolve2.permissions = TICKET_MODIFY
resolve2.set_resolution = Invalid, Duplicate, WontFix
resolve3 = in-progress -> closed
resolve3.name = resolve
resolve3.operations = set_resolution
resolve3.permissions = TICKET_MODIFY
resolve3.set_resolution = WorksForMe, Invalid, Duplicate, WontFix
setfixed = in-progress -> fixed
setfixed.name = mark as fixed
setfixed.permissions = TICKET_MODIFY
setinprogress = verified, fixed -> in-progress
setinprogress.name = ticket need to be re-worked
setinprogress.permissions = TICKET_MODIFY
setverified = fixed -> verified
setverified.name = mark as verified
setverified.permissions = TICKET_MODIFY

Comments

Popular posts from this blog

Web application framework comparison by memory consumption

Python vs JS vs PHP for embedded systems