Contribute/Coding/Triage

Improving the triage process.

Mike Hoye and Marcia Knous have a Q2/15 goal of triaging 100% of daily incoming bugs. In order to accomplish this, we need to have a crisp definition of what constitutes a non-triaged bug, and what "triage" is.

One naive and narrowly-scoped approach would be to set a goal of getting all the bugs from the (Firefox/Core/Toolkit)::Untriaged components and file them in the correct component. Perhaps unsurprisingly this would be both easy to achieve and not particularly helpful.

A better way to see triage is as a process rather than a binary state: to get a bug from "an unconfirmed bug from an new contributor" to "an engineer can make an informed decision about how to proceed". To get there, a bug may need:

• A clean-profile confirmation
• A testcase or STR
• A regression range
• Confirmation on a different OS
• Other assistance

There are obvious benefits to this approach for engineers and managers; the challenge is that:

1. Working to this definition we're looking at one to three hundred bugs per day.
2. Triaging bugs to this standard is a tedious, unconsidered process in Bugzilla as it stands.
3. We don't currently have a way to find or flag bugs as bugs as being in this intermediate "in-triage" state.

Our proposed approach is four:

1. Dramatically reduce triage and triage-followup friction. We're doing this in two ways: the number of steps involved and by polishing up Gijs' addon so we can make adding whiteboard flags (regression-range-needed, etc) and followup boilerplate (can you reproduce with a clean profile, here is a link to how to do that, etc) a matter of a few clicks.
2. Make it much easier for community members to become a part of the triage process. This is happening in 1153108 that lets users grant themselves canconfirm permissions, surfacing that contribution avenue in Bedrock, and improving our training documentation.
3. Adding some keywords to Bugzilla and changing some processes so that bugs in-triage are not getting lost. [1] proposes to remove the "untriaged" components of Firefox::, Core:: and Toolkit:: and [2] proposes adding "in-triage" and "ready" status flags.

Having these things in place, we can then take advantage of Graydon's helper email tool that lets contributors sign up to triage X number of bugs over Y period of time. Graydon reports that this has been a very successful approach for the Rust community. To our back-of-the-envelope estimates - better numbers coming - the combination of an easier process, better tooling, better documentation and low-cost, low-touch involvement should let us get to a point where we can get our proverbial chins above the tide and keep them there.