RT has gotten a lot better in the last couple years. I used to find it horribly slow and unwieldy, but the folks at Best Practical have made several nice improvements that are making it a useful tool for me to manage issues across the growing list of modules I wrote or help maintain. For example:
- It’s much faster
- Severity is now alphabetically sortable (Critical, Important, Normal, Unimportant, Wishlist)
- A “patched” option has been added as to the “status” field
- The home page gives a nice dashboard overview of tickets
Here’s a quick overview of how I use it to manage bugs and other tickets. I’m not perfect at this process yet, but this is what I’m aspiring to and it’s worked very well recently in triaging bugs in Module::Build, ExtUtils::CBuilder and ExtUtils::ParseXS.
For all new or stale tickets, here’s my triage process:
- If the subject field doesn’t tell me what work needs to be done, I change it so I can see at a glance in the dashboard what the ticket entails
- If a patch is attached, I prepend “[PATCH]” to the subject line. If it’s a speculative patch, I might use “[PATCH?]” instead. This tells me that the work to be done is applying and testing a patch, not writing a fix from scratch
- I get the severity right. This is a judgment call, but, to me, generally “Critical” means things are badly broken everywhere, “Important” means badly broken for a few major platforms/perl versions, “Unimportant” means cosmetic, documentation or efficiency problems, “Wishlist” is new features and “Normal” is everything else. (See below for a more specific example for Module::Build)
- Duplicate tickets get merged together
- Once I’ve looked at a new bug and made the fixes above, I change the status from “new” to “open”. This signals to me that triage is done for that ticket.
- Once a bug is fixed, I change the status to “patched” until the next non-dev release. This lets anyone else wanting to report the same issue see that the issue is addressed.
- Anything that I consider a “wont fix” problem gets changed to “resolved”. (I don’t use “rejected” unless the report itself is in error.)
- Anything that is waiting on feedback from someone before any work can proceed to fix the ticket gets marked “stalled”
With a little up-front investment using this system, I can pretty quickly see where I might spend any “round tuits” I have and spend less time figuring out where to get started.
For me, getting the severity right is one of the most useful things in prioritizing my time. Here are the severity criteria I used when triaging existing bugs in Module::Build:
- Critical – OMYGODIBROKECPAN issues; installing M::B cripples subsequent module installations
- Important – M::B won’t install or function correctly on a major OS or for a major class of distributions (e.g. XS)
- Normal – core user actions (build/test/install) or author actions (meta/manifest/dist*) broken in specific but not widespread situations or where clear workarounds exist (e.g. using Build.PL instead of M::B::Compat Makefile.PL)
- Unimportant – author ‘helper’ actions broken, documentation issues,things that annoy authors using M::B
- Wishlist – new features, options or DWIMmery
Before releasing 0.34, I set a goal to eliminate the Critical and Important bugs and reduce the list of Normal bugs as much as I could without spending tons of time on any particular bug. With the list set, I just worked top down until I ran out of time or got bogged down. Easy!
So while I didn’t think I’d ever say it, thank you, Best Practical for making RT something that finally works (more or less) the way I want it to.