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:
- Working to this definition we're looking at one to three hundred bugs per day.
- Triaging bugs to this standard is a tedious, unconsidered process in Bugzilla as it stands.
- 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 threefold:
- 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.
- 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.
- Adding some keywords to Bugzilla and changing some processes so that bugs in-triage are not getting lost. [1] and