ReleaseEngineering/Bugzilla/Triage
Guiding principles for releng bug triage
The RelEng team keeps bugs in three general buckets:
- untriaged: new bugs that are not yet assigned;
- triaged: bugs assigned to RelEng team members; and,
- "future": bugs that are not urgent, are scheduled for later (e.g. quarterly goals), or enhancements.
Individual team members handle their own bugs in different ways. Most team members will switch bugs from NEW to ASSIGNED when they begin working on them. Some may even set the Priority flag. If they do use the Priority field, the Priority levels have these generally accepted meanings:
- P1: blocker bug: other bugs are on hold until this is fixed;
- P2: In Progress;
- P3: Next up: someone is working on, or planning to work, on it;
- P4: Bug is blocked by another bug or some external task. A Quarterly Goal;
- P5: Non-critical work / enhancement
Nobody is working on my bug. Help!
We're always striving to get better about fixing bugs and how we handle the bugs we're not currently fixing. Even with a larger team, there are still many more things to work on than there are people available to work on them. If you have a bug that is not currently assigned to someone on the RelEng team, there are a few things you can do to increase the chances receiving prompt attention:
Things that help:
- follow the Bug Writing guidelines. The more information you can put in the bug, the easier we will be able to track down the problem and fix it.
- ask to borrow a machine: if you have the time and inclination, you can debug problems on our hardware. See bhearsum's blog post on the subject for more info.
Things that don't help:
- assigning bugs directly to a release engineer
- adjusting bug priorities yourself, with the exception of blocker bugs
- voting for bugs in bugzilla. For whatever reason, bug votes have never been used for anything other than trivia in the Mozilla community.
See Also
Other pages about ReleaseEngineering's use of bugzilla - please keep these up to date!
