Bug Triage/Projects/Bug Handling/Triage Rules
Hi, you're participating in the Bug Triage pilot, or you're interested in our work, thanks. Here's a guide on how to triage bugs in your component using our rules and categories.
- 1 Set Up Your Bug Queries
- 2 Triage
- 3 Decisions
- 4 Edge Cases
Set Up Your Bug Queries
In bugzilla, open a new bug query, set it for bugs in the component(s) you're interested in, all statuses, resolution equal to `---`, and bugs that have a creation date of the day you start daily triage to now. In the advanced search rules choose bugs that do not have the string `btpp-` in whiteboard tags, and do not have the `needinfo` flag set. Make sure the search results display keywords and whiteboard tags.
Save that query as `My Component Untriaged`.
Now modify the saved search, removing the does not have `needinfo` rule, and changing the the whiteboard query to has the string `btpp-`.
Save that as `My Component Triaged`.
I recommend you start triaging every day. You will soon know if you can back off to every other day. If you have a small flow of bugs in your component, just run the query daily and check.
If you're overwhelmed, get help. Other engineers and volunteers on your team should be comfortable triaging bugs, and you should have faith in their ability to do so.
Say NO early
The thing I really want you to get comfortable with is saying no to a bug, especially enhancement requests. If it's something you don't think your team will undertake, seriously consider closing with resolution `WONTFIX`.
If you have lots of bugs and limited time, look the ones with crash, regression, and security-related keywords first. Follow crash report links and see what versions and how many people are affected.
|btpp-fix-now||Bug is a critical crash or regression that should be fixed before it goes out in a release||Bug needs to be assigned, have release flags set, and set P1|
|btpp-active||Bug is non-critical, but being worked on as part of a teams' regular iteration||Bug should be assigned|
|btpp-fix-later||Bug will be worked on soon||Set P2 on the bug|
|btpp-triage-followup-YYYY-MM-DD||You can't make a decision on the bug, but will by a week from now||Bug should have `needinfo` set or a dependency bug linked|
|btpp-triage||This bug is not urgent and its final disposition is deferred to the team's triage meeting||If the component doesn't have a standing triage meeting, this option should not be used|
|btpp-backlog||This is a legitimate bug, you'll accept a patch for it, but there are no plans to work on it||Set P3|
|btpp-close||On further review, this bug can be closed, or if it's a feature request, WONTFIX'ed||Set status to CLOSED and appropriate resolution|
Things you are doing now
- these are the bugs that need an immediate fix to keep from shipping crashes and regressions, if you mark the bug with this tag, you need to have it assigned to someone, set the release flags for the versions affected, and the priority to `P1`.
Signs this bug is a crash or regression
- crash, topcrash, regression
- Words in summary
- crash, regression
- Group restrictions
- links to crash logs, links to specifications
There's no access control in bugzilla on keywords, and priority/severity, so check who set those.
- sometimes your team will jump on a bug, or a member of the community is working on it, even if it's not urgent, make sure there's a person assigined, a mentor if it's a volunteer, and release flags.
I don't know what to do with this bug
`needinfo` is your friend. If you set `needinfo`, add the whiteboard tag `btpp-triage-followup-YYYY-MM-DD` with the date set for a week from now. You'll be watching this in your queries, and if it doesn't get answered, you'll need to escalate if it's a crash or regression, or consider closing it if it's not reproducible.
This bug is real, but not worth the investment
Mark the bug with the whiteboard tag `btpp-backlog` and set priority to `P3`.
I want to do this, but not now
Mark the bug with the whiteboard tag `btpp-fix-later`, and the priority to `P2`. While this isn't the timebox of the pilot, we intend for you to visit these bugs within three months and decide if you're working on them, putting them in `btpp-backlog`, or closing them.
This should be closed
Mark the bug with the `btpp-closed` whiteboard tag, and set status to `CLOSED` with the appropriate resolution. Again, if it's a feature request you don't think you'll be able to take on, close it.
[meta] and tracking bugs
Bugs for your regular triage
If you want to defer a bug to a standing triage meeting, add the whiteboard tag `btpp-triage`. We expect that the bug is not a btpp-fix-now, and that you'll move this bug to another state at your triage.