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 a solid definition of what constitutes a non-triaged bug and a crisp understanding of what "triage" is.

The easy way won't help much.

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. We believe that this is a low bar, and would be easy to achieve but only marginally helpful.

The better way will help a lot.

A better way to view triage is as a process rather than a binary state, whose goal is to get a bug from "an unconfirmed issue from an new contributor" to "a well-defined problem that the responsible engineer can make an informed decision about". Ideally the bug would be low- or no-touch for that engineer up until it reaches that ready state; realistically, getting it as far down that path as possible before it needs attention would be a victory.

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 slow, difficult and unconsidered process.
3. We don't currently have a reliable way to find or flag bugs as bugs as being in this intermediate "in-triage" state.

Our proposed approach (v1.2) is:

1. Dramatically reduce triage and triage-followup friction. We're doing this in two ways: minimizing the number of steps involved and by polishing up Gijs' triage-helper 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 bug 1153108 that lets users grant themselves canconfirm permissions, surfacing that contribution avenue in Bedrock, and improving our training documentation.
3. At Gavin's suggestion, using an in-bugzilla but not-UI-visible flag to Bugzilla to denote whether or not a bug mid-triage-process, where

• [?] -> pre-triage
• [+] -> in triage
• [-] -> Triage done, bug should be ready to set to "NEW" and bring to an engineer's attention

This will facilitate tooling, community ownership of the process, and prevent contributers doing triage from stepping on each others' toes.

Having these things in place, we can then take advantage of Graydon's triage 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.

Revisions:

In V1 of this proposal, 1154031 proposed to remove the "untriaged" components of Firefox::, Core:: and Toolkit:: and 1155386 proposed adding "in-triage" and "ready" status flags. Both of those bugs have been RESOLVED INCOMPLETE for now.

V1.1 proposed an "in-triage" status keyword to Bugzilla, which has been changed to a non-UX-visible flag at Gavin's suggestion.