Bug Triage/Projects/Bug Handling/Triage Rules

From MozillaWiki
Jump to: navigation, search

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.

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.

State Description Notes
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.

Edge Cases

[meta] and tracking bugs

Ignore these.

The Hello team has two existing triage whiteboard tags which they use: [triage] and [uxtriage].


Ignore these.

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.