Changes to DrProject’s Ticketing System
December 16th, 2006
Here’s a draft proposal for modifying DrProject‘s ticketing system based on feedback from the post-mortem:
- State is simply “open” or “closed”, and becomes implicit: the buttons to update a ticket are labeled “Preview”, “Update”, and “Close”.
- Tickets can be assigned to roles, as well as to specific users, so that if an organization distinguishes “tester” from “developer”, tickets can be marked accordingly.
- Get rid of “type”: if people want to distinguish different kinds of tickets, they can evolve a set of tags. (This is the same argument we used to get rid of the “component” field inherited from Trac.)
Still unsure what to do about actual and estimated effort: companies want it, but we know that student teams won’t use it (or that if they do, their numbers will be science fiction). Is a “small/medium/large” pulldown when filing the ticket enough, if people can adjust it again when closing the ticket to show actual effort?
This sounds like a step in the right direction (for my tastes anyway).
Certainly I can see the benefit of distinguishing jobs as being large/medium/small and adding several details.
But I found that being forced to classify jobs every time I wanted to just add a simple “to-do” made me eventually ignore the entire field altogether since I’ve already filled in bogus info more than once.
I think it’s important to discuss with the members of your project what details are important to them and what details aren’t.
I would like to see a system where you give us the option to specify what fields within the ticketing system are manditory and which are optional. Perhaps on a per-project basis.