Contribute/Coding/Triage: Difference between revisions
m (wording) |
(Update of the project for July 20th 2015.) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
'''<big>Improving the triage process.</big>''' | '''<big><strike>Improving the triage process.</strike></big>''' | ||
'''<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. | |||
To get there, a bug may need: | |||
* A clean-profile confirmation | * A clean-profile confirmation | ||
* A testcase or STR | * A testcase or STR | ||
* A regression range | * A regression range | ||
* Confirmation on a different OS | * Confirmation on a different OS or device | ||
* Other | * Other clarification | ||
We intend to expand and refine Gijs' triage-helper addon to facilitate this process. | |||
An outline of our planned approach from earlier in the project follows: | |||
'''<big>Our proposed approach is:</big>''' | '''<big>Our proposed approach (v1.2) is:</big>''' | ||
# 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. | ||
# Make it much easier for community members to become a part of the triage process. This is happening in [https://bugzilla.mozilla.org/show_bug.cgi?id=1153108 bug 1153108] that lets users grant themselves canconfirm permissions, surfacing that contribution avenue in Bedrock, and improving our training documentation. | # Make it much easier for community members to become a part of the triage process. This is happening in [https://bugzilla.mozilla.org/show_bug.cgi?id=1153108 bug 1153108] that lets users grant themselves canconfirm permissions, surfacing that contribution avenue in Bedrock, and improving our training documentation. | ||
# | # At Gavin's suggestion, using an in-bugzilla but tools-but-not-UI-visible flag to Bugzilla to denote whether or not a bug is in mid-triage-process, where | ||
* [?] -> Untriaged | |||
* [+] -> In triage | |||
Bugs making it past "In triage" will be moved from UNCONFIRMED to NEW, and should be game-ready for engineer inspection. This will facilitate tooling, community ownership of the process, and prevent contributors doing triage from stepping on each others' toes. | |||
Having these things in place, we can then take advantage of Graydon's [https://github.com/graydon/triage 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. | Having these things in place, we can then take advantage of Graydon's [https://github.com/graydon/triage 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, [https://bugzilla.mozilla.org/show_bug.cgi?id=1154031 1154031] proposed to remove the "untriaged" components of Firefox::, Core:: and Toolkit:: and [https://bugzilla.mozilla.org/show_bug.cgi?id=1155386 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 binary flag at Gavin's suggestion. | |||
Latest revision as of 20:13, 20 July 2015
Improving the triage process.
TRIAGE ALL THE THINGS
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.
This is only a first step.
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.
To get there, a bug may need:
- A clean-profile confirmation
- A testcase or STR
- A regression range
- Confirmation on a different OS or device
- Other clarification
We intend to expand and refine Gijs' triage-helper addon to facilitate this process.
An outline of our planned approach from earlier in the project follows:
Our proposed approach (v1.2) is:
- 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.
- 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.
- At Gavin's suggestion, using an in-bugzilla but tools-but-not-UI-visible flag to Bugzilla to denote whether or not a bug is in mid-triage-process, where
- [?] -> Untriaged
- [+] -> In triage
Bugs making it past "In triage" will be moved from UNCONFIRMED to NEW, and should be game-ready for engineer inspection. This will facilitate tooling, community ownership of the process, and prevent contributors 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 binary flag at Gavin's suggestion.