The author of a recent O’Reilly book, The Art of Project Management, just posted on article titled “How to Decide What Bugs to Fix When, Part 1.”
Much of this article is quite easy to apply to Bugzilla, which suggests to me that either all good bug databases have similar features or the author likes the Bugzie.
For example, he says we should split bugs into multiple priority and severity levels, combining both when deciding whether to fix something. He defines priority like this, with a 4-level scheme:
- Priority 1: Must fix
- Priority 2: Might fix
- Priority 3: Probably won’t fix
- Priority 4: Won’t fix until hell freezes over
And then we can use severity to define how major a bug is when it hits somebody (combination of my definitions and Bugzilla’s), regardless of how often it hits people:
- Blocker: Breaks their systems, loses their data, requires reinstallation
- Critical: Crashes, loss of data, severe memory leak
- Major: Major loss of function (e.g., an e-mail client where you can’t send e-mail)
- Minor: Minor loss of function, or other problem where easy workaround is present
- Trivial: Cosmetic problem like misspelled words or misaligned text
To decide which bugs to fix, we first sort by priority to get a list of bugs we even care about. Then, we sort by severity to know where to start.
For anybody with an overwhelming bug list, you might like to start using Bugzilla’s priority field. I know I plan to.