Bug Triage/Projects/Bug Handling

Bug Reports are a rough unit of quality, represent risk, and a unit of community interaction.

Responding to new bugs in a timely fashion, and coming to an actionable decision on the future of each bug means that: we can catch more regressions and other bugs that cause us to have to ship point releases, encourage contributors to file more good bugs, and reduce the psychic weight of bugs left in limbo on Mozillans.

Scope

This project covers bugs in Core, Toolkit, Firefox, and Fennec components in Bugzilla.

Triage Leads

We've identified leads for 80% of these components. These people will be responsible for making sure new bugs landing in components, are acted on in a timely fashion, new bugs are now being moved into components by volunteers and Mozilla's contractors. Triage leads are encouraged to delegate the work to other members of their team, and set up rotations for reviewing bugs [see Networking].

In a separate project, another team is building groups of volunteers to help with classification of new bugs in a component.

Pilot Project

During February 2016, we are running a pilot bug classification project with the Hello, DOM, and Developer Tools teams.

In daily triages, bugs are marked with one of the following whiteboard tags representing a state:

btpp-fix-now

bug is a critical crash, regression, or security bug which should be worked on immediately. Bugs classified as such should have a developer assigned, a priority of `P1`, and flags set for the affected releases

btpp-active

bug is being worked on, but is not critical. The bug should have a developer assigned

btpp-triage-followup-YYYY-MM-DD

bug needs more information by YYYY-MM-DD, which is a week from the day this tag is assigned. Bug should have needinfo set, and the whiteboard tag removed when the needinfo flag is resolved. Once this is resolved, the triager must move it to one of the -fix-now, -active, -fix-later, -backlog, or -close states.

btpp-fix-later

bug is not critical, not being worked on, but teams commits to scheduling within the next quarter

btpp-backlog

bug is not critical, and the team has no plans to work on it, but will accept a patch

btpp-close

bug has been closed. Teams are encouraged to close bugs if they do not plan to undertake the work.

Triage teams will have to follow up on these tags by hand during the pilot, and we expect bugs that are `btpp-fix-now` will be tracked by the team to confirm they are going into releases.

Current Status

The new triage process is being presented at the 2016 London AllHands.

Bugs are now displaying readable triage statuses in bugzilla's new modal view (which will be become the default in Q3 2016.)

Next Step

In the third quarter we'll support teams as they start triaging bugs, and making more changes to bugzilla's UI to support triage.