Mozilla

Firefox Bug Handling

Triage for Bugzilla

↩︎ Home » Triage Process for Firefox Components in Mozilla-central and Bugzilla

Expectations

All teams working on Firefox using either or both Mozilla-central and Bugzilla are expected to follow the following process.

Why Triage

We want to make sure that we looked at every defect and a priority has been defined. This way, we make sure that we did not miss any critical issues during the development and stabilization cycles.

Staying on top of the bugs in your component means:

Who Triages

Engineering managers and directors are responsible for naming the individuals responsible for triaging defect and task bugs in a component.

We use Bugzilla to track this. See the list of triage owners.

If you need to change who is responsible for triaging a bug in a component, please file a bug against bugzilla.mozilla.org in the Administration component. When a new component is created, a triage owner must be named.

What Do You Triage

As a triage owner the queries you should be following for your component are:

There’s a tool to help you find bugs https://mozilla.github.io/triage-center/ and the source is at https://github.com/mozilla/triage-center/.

These bugs are reviewed in the weekly Regression Triage meeting

If a bug is an enhancement it needs a priority set and a target release or program milestone. These bugs are normally reviewed by product managers. Enhancements can lead to release notes and QA needed that we also need to know about

If a bug is a task resulting in a changeset, release managers will need to known when this work will be done. A task such as refactoring fragile code can be risky.

Weekly or More Frequently (depending on the component) find un-triaged bugs in the components you triage.

For each bug decide priority (you can override what’s already been set, as a triage lead, you are the decider.)

Priority Description
No decision
P1 Fix in the current release cycle
P2 Fix in the next release cycle or the following (nightly + 1 or nightly + 2)
P3 Backlog
P4 Do not use, this priority is for web platform test bots
P5 Will not fix, but will accept a patch

What About Release Status (status_firefoxNN) Flags

Release status (and tracking) flags are set independent of triage decisions, but should be consistent with triage decisions.

Also, as a release approaches, the release status of open, high priority (P1) bugs can change. Triagers and engineering leads must review open bugs with a release status of affected and fix_optional, and decide which of these to keep, and move the others to wontfix for the current cycle.

The flag status_firefoxNN has many values, here’s a cheat sheet.

? unaffected affected fixed
? unaffected   wontfix verified
  affected   fix-optional disabled
      fixed verified-disabled

The headers of the table are values of the status flag. Each column are the states reachable from the column headings.

Automatic Triage Overrides

When a bug is tracked for a release, i.e. the tracking_firefoxNN flag is set to + or blocking triage decisions will be overriden, or made as follows:

Because bugs can be bumped in priority it’s essential that triage owners review their P1 and P2 bugs frequently.

Questions and Edge Cases

This bug is a feature request

Set the bug’s type to enhancement, add the feature keyword if relevant, and state to NEW. This bug will be excluded from future triage queries.

This bug is a task, not a defect

Set the bug’s type to task, and state to NEW. This bug will be excluded from future triage queries.

If you are not sure of a bug’s type, check our rules for bug types.

This bug’s state is UNCONFIRMED

Are there steps to reproduce? If not, needinfo the person who filed the bug, requesting steps to reproduce. You are not obligated to wait forever for a response, and bugs for which open requests for information go unanswered can be RESOLVED as INCOMPLETE.

I don’t have enough information to make a decision

If you don’t have a reproduction or confirmation, or have questions about how to proceed, needinfo the person who filed the bug, or someone who can answer.

The stalled keyword

The extreme case of not-enough-information is one which cannot be answered with a needinfo request. The reporter has shared all they know about the bug, we are out of strategies to take to resolve it, but the bug should be kept open.

Mark the bug as stalled by adding the stalled keyword to it. The keyword will remove it from the list of bugs to be triaged.

If a patch lands on a stalled bug, automation will remove the keyword. Otherwise, when the keyword is removed, the bug will have its priority reset to -- and the components triage owner notified by automation.

Bugs which remain stalled for long periods of time should be reviewed, and closed if necessary.

This doesn’t fit into a P1, P2, P3, P4, or P5 framework

Mark it as a P3.

If it’s a tracking bug, make sure has “[meta]” in the title and has the meta keyword added. This will remove it from the list of untriaged bugs.

Bug is in the wrong Component

Remove any priority set, then either move to what you think is the correct component, or needinfo the person responsible for the component to ask them.

I don’t think we should work on it at any time

If you’ll accept a patch, mark it as P5, otherwise, close it as WONTFIX

My project is on GitHub

We have a guide for GitHub projects to follow when triaging.

Watch open needinfo flags

Don’t let open needinfo flags linger for more than two weeks.

Close minor bugs with unresponded needinfo flags.

Follow up on needinfo flag requests.

The tool will help you find these (the query is imperfect.)

End of Iteration/Release Cycle

Review P1s

Are there unresolved P1s?

Revisit their priority, and move to backlog (P3.)

Review P2s

Are there P2s that should move to P1s for the next cycle?

Are there P2s you now know are lower priority, move to P3.

Review P3s

Are their P3 bugs you now know you won’t get to? Either demote to P5 (will accept patch) or resolve as WONTFIX.

Tools

Triage with me

One tool we use in addons is triage-with-me. Its a Firefox Add-on that sends all the pages you click on in bugzilla into a server which then sends the URL to everyone else in the triage. – Andy McKay

The upshot is, one person clicks on links in Bugzilla, the bugs open up on everyone else’s computer.

Questions

Mozilla Public, Repository