Contribute/Coding/Triage: Difference between revisions

Jump to navigation Jump to search

Contribute/Coding/Triage (view source)

Revision as of 20:13, 20 July 2015

169 bytes removed ,  20 July 2015
Update of the project for July 20th 2015.
(decomplicated the in-triage flag.)
(Update of the project for July 20th 2015.)
 
Line 1: Line 1:
'''<big>Improving the triage process.</big>'''
'''<big><strike>Improving the triage process.</strike></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 a solid definition of what constitutes a non-triaged bug and a crisp understanding of what "triage" is.
'''<big>TRIAGE ALL THE THINGS</big>'''
 
Mike Hoye and Marcia Knous have a Q2/Q3 goal of triaging 100% of daily incoming bugs. In order to accomplish this, we have stood up TriageBot, a public-facing service aimed at connecting contributors with bugs that need love.
 
Triagebot is live now (July 20th) and we're passing it around to Mozilla's staff, Reps, and student ambassadors. The plan currently is to keep it running as-is, measure our results after approximately 2 weeks and start advertising it more widely as we start to see success.
 
 
'''<big>This is only a first step.</big>'''
 
Getting a bug into the right component matters a lot, but it's not the only thing. Triage is not a binary state, but a process 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.


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


'''<big>The better way will help a lot.</big>'''


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:
To get there, a bug may need:
Line 19: Line 24:
* Other clarification
* Other clarification


There are obvious benefits to this approach for engineers and managers; the challenge is that:
We intend to expand and refine Gijs' triage-helper addon to facilitate this process.


# Working to this definition we're looking at one to three hundred bugs per day.
An outline of our planned approach from earlier in the project follows:
# Triaging bugs to this standard is a slow, difficult and (currently) unconsidered process.
# We don't currently have a reliable way to find or flag bugs as bugs as being in this intermediate "being-triaged" state.


'''<big>Our proposed approach (v1.2) is:</big>'''
'''<big>Our proposed approach (v1.2) is:</big>'''
Mhoye
Confirmed users, Bureaucrats and Sysops emeriti
421

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/1085709"

Navigation menu