Confirmed users, Bureaucrats and Sysops emeriti
421
edits
(First draft concludes.) |
mNo edit summary |
||
Line 1: | Line 1: | ||
'''Improving the triage process.''' | '''<big>Improving the triage process.</big>''' | ||
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. | 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. | ||
'''<big>The easy way won't help much.</big>''' | |||
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. | 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. | ||
'''<big>The better way will help a lot.</big>''' | |||
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 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: | ||
Line 19: | Line 23: | ||
# We don't currently have a way to find or flag bugs as bugs as being in this intermediate "in-triage" state. | # 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 | Our proposed approach is: | ||
# Dramatically reduce triage and triage-followup friction. We're doing this in two ways: [https://bugzilla.mozilla.org/show_bug.cgi?id=1151745|minimizing the number of steps involved] and by polishing up Gijs' [https://github.com/gijsk/triage-helper|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. | # Dramatically reduce triage and triage-followup friction. We're doing this in two ways: [https://bugzilla.mozilla.org/show_bug.cgi?id=1151745|minimizing the number of steps involved] and by polishing up Gijs' [https://github.com/gijsk/triage-helper|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. |