Contribute/Coding/Triage - Revision history

Mhoye: Update of the project for July 20th 2015.

2015-07-20T20:13:15Z

Update of the project for July 20th 2015.

← Older revision		Revision as of 20:13, 20 July 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: decomplicated the in-triage flag.

2015-04-27T14:16:57Z

decomplicated the in-triage flag.

← Older revision		Revision as of 14:16, 27 April 2015
Line 16:		Line 16:
	* 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 ~~assistance~~		* Other clarification

	There are obvious benefits to this approach for engineers and managers; the challenge is that:		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.		# Working to this definition we're looking at one to three hundred bugs per day.
	# Triaging bugs to this standard is a slow, difficult and unconsidered process.		# 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 "in-~~triage~~" state.		# 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>'''
Line 29:		Line 29:
	# 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 not-UI-visible flag to Bugzilla to denote whether or not a bug mid-triage-process, where		# 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
	* [?] -> ~~pre-triage~~		* [?] -> Untriaged
	* [+] -> in 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.		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:		Revisions:
Line 43:		Line 41:
	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.		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 flag at Gavin's suggestion.		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.

Mhoye: Update to 1.2

2015-04-23T20:44:46Z

Update to 1.2

← Older revision		Revision as of 20:44, 23 April 2015
Line 25:		Line 25:
	# We don't currently have a reliable way to find or flag bugs as bugs as being in this intermediate "in-triage" state.		# We don't currently have a reliable way to find or flag bugs as bugs as being in this intermediate "in-triage" state.

	'''<big>Our proposed approach (v1.1) 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.
	# ~~Adding~~ an "in-~~triage" status keyword~~ to Bugzilla to ~~flag that~~ a bug is in ~~this intermediate state between~~ "~~unconfirmed~~" and ~~"new", with bugs making it~~ to ~~"new" when they're (more) ready for~~ an ~~engineering decision. The transition from "in-triage" to "new" means that this bug is ready for~~ engineer's attention.		# 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 [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.


	(In ~~previous versions~~ 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.)
			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 flag at Gavin's suggestion.

Mhoye: Partial update towards a minimum-viable-product, moving "close the untriaged category" and the "Ready" status flag out of scope.

2015-04-21T20:48:05Z

Partial update towards a minimum-viable-product, moving "close the untriaged category" and the "Ready" status flag out of scope.

← Older revision		Revision as of 20:48, 21 April 2015
Line 25:		Line 25:
	# We don't currently have a reliable way to find or flag bugs as bugs as being in this intermediate "in-triage" state.		# We don't currently have a reliable way to find or flag bugs as bugs as being in this intermediate "in-triage" state.

	'''<big>Our proposed approach is:</big>'''		'''<big>Our proposed approach (v1.1) 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.
	# Adding ~~some keywords~~ to Bugzilla and ~~changing some processes so that~~ bugs ~~in-triage are not getting lost. [https://bugzilla.mozilla.org/show_bug.cgi?id=1154031 1154031] proposes~~ to ~~remove the~~ "~~untriaged~~" ~~components of Firefox::, Core:: and Toolkit:: and [https://bugzilla~~.~~mozilla.org/show_bug.cgi?id=1155386 1155386] proposes adding~~ "in-triage" ~~and~~ "ready~~" status flags~~.		# Adding an "in-triage" status keyword to Bugzilla to flag that a bug is in this intermediate state between "unconfirmed" and "new", with bugs making it to "new" when they're (more) ready for an engineering decision. The transition from "in-triage" to "new" means that this bug is ready for engineer's attention.

	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.


			(In previous versions 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.)

Mhoye at 21:21, 16 April 2015

2015-04-16T21:21:39Z

← Older revision		Revision as of 21:21, 16 April 2015
Line 22:		Line 22:

	# Working to this definition we're looking at one to three hundred bugs per day.		# 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~~.		# Triaging bugs to this standard is a slow, difficult and unconsidered process.
	# We don't currently have a reliable way to find or flag bugs as bugs as being in this intermediate "in-triage" state.		# We don't currently have a reliable way to find or flag bugs as bugs as being in this intermediate "in-triage" state.

Mhoye: wording

2015-04-16T21:20:44Z

wording

← Older revision		Revision as of 21:20, 16 April 2015
Line 5:		Line 5:
	'''<big>The easy way won't help much.</big>'''		'''<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. 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>'''		'''<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 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 clean-profile confirmation

Mhoye: wording

2015-04-16T21:15:04Z

wording

← Older revision		Revision as of 21:15, 16 April 2015
Line 1:		Line 1:
	'''<big>Improving the triage process.</big>'''		'''<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 a solid definition of what constitutes a non-triaged bug and a crisp understanding of what "triage" is.

	'''<big>The easy way won't help much.</big>'''		'''<big>The easy way won't help much.</big>'''

Mhoye at 21:13, 16 April 2015

2015-04-16T21:13:02Z

← Older revision		Revision as of 21:13, 16 April 2015
Line 25:		Line 25:
	'''<big>Our proposed approach is:</big>'''		'''<big>Our proposed approach 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.
	# Adding some keywords to Bugzilla and changing some processes so that bugs in-triage are not getting lost. [https://bugzilla.mozilla.org/show_bug.cgi?id=1154031\| 1154031] proposes to remove the "untriaged" components of Firefox::, Core:: and Toolkit:: and [https://bugzilla.mozilla.org/show_bug.cgi?id=1155386\| 1155386] proposes adding "in-triage" and "ready" status flags.		# Adding some keywords to Bugzilla and changing some processes so that bugs in-triage are not getting lost. [https://bugzilla.mozilla.org/show_bug.cgi?id=1154031 1154031] proposes to remove the "untriaged" components of Firefox::, Core:: and Toolkit:: and [https://bugzilla.mozilla.org/show_bug.cgi?id=1155386 1155386] proposes adding "in-triage" and "ready" status flags.

	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.

Mhoye at 21:10, 16 April 2015

2015-04-16T21:10:39Z

← Older revision		Revision as of 21:10, 16 April 2015
Line 21:		Line 21:
	# Working to this definition we're looking at one to three hundred bugs per day.		# 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.		# 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.		# 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 is:		'''<big>Our proposed approach 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~~%20~~\|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.
	# Adding some keywords to Bugzilla and changing some processes so that bugs in-triage are not getting lost. [https://bugzilla.mozilla.org/show_bug.cgi?id=1154031\|1154031] proposes to remove the "untriaged" components of Firefox::, Core:: and Toolkit:: and [https://bugzilla.mozilla.org/show_bug.cgi?id=1155386\|1155386] proposes adding "in-triage" and "ready" status flags.		# Adding some keywords to Bugzilla and changing some processes so that bugs in-triage are not getting lost. [https://bugzilla.mozilla.org/show_bug.cgi?id=1154031\| 1154031] proposes to remove the "untriaged" components of Firefox::, Core:: and Toolkit:: and [https://bugzilla.mozilla.org/show_bug.cgi?id=1155386\| 1155386] proposes adding "in-triage" and "ready" status flags.

	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.

Mhoye at 21:07, 16 April 2015

2015-04-16T21:07:44Z

← Older revision		Revision as of 21:07, 16 April 2015
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 ~~four~~:		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.