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.

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`.

Triage

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`.

Decisions

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.

Things you are doing now

btpp-fix-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

Keywords
crash, topcrash, regression
Words in summary
crash, regression
Group restrictions
Security-related-
Priority
P1
Comments
links to crash logs, links to specifications

Check who set the bug's metadata, we don't put keywords, or priority/severity under access control.

btpp-active
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

For the moment, 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`. The expectation is that you'll move this bug to another category at your triage.