Hi Emma,
for those of us that are addicted to data: You have about a 1000 bugs of
data, and I'd love to hear some of the good parts, and maybe also some
of the bad parts.
Also, you tested on three teams, and you report a success story from
one. Could you frame that a bit? Is that within the expectations, or
above or below?
Axel
On 29/03/16 22:07, Emma Humphries wrote:
tl;dr
In Quarter Two I'm implementing the work we’ve been doing to improve
triage, make actionable decisions on new bugs, and prevent us from shipping
regressions in Firefox.
Today I’m asking for feedback on the plan which is posted at:
https://docs.google.com/document/d/1FFrtS0u6gNBE1mxsGJA9JLseJ_U6tW-1NJvHMq551ko
Allowing bugs to sit around without a decision on what we will do about
them sends the wrong message to Mozillans about how we treat bugs, how we
value their involvement, and reduces quality.
The Firefox quality team (myself, Mike Hoye, Ryan VanderMeulen, Mark Cote,
and Benjamin Smedberg) want to make better assertions about the quality of
our releases by giving you tools to make clear decisions about which bugs
must be fixed for each release (urgent) and actively tracking those bugs.
What We Learned From The Pilot Program
During the past 6 weeks, we have prototyped and tested a triage process
with the DOM, Hello, and Developer Tools teams.
Andrew Overholt, who participated in the pilot for the DOM team, said, “A
consistent bug triage process can help us spread the load of watching
incoming bugs and help avoid issues falling through the cracks."
During the pilot, the DOM team uncovered critical bugs quickly so that
people could be assigned to them.
The pilot groups also found that the triage process needs to be fast and
have tooling to make going through bugs fast. It’s easy to fall behind on
triage for a component, but if you stay up to date it will take no more
than 15 minutes a day.
You can find the bugs we triaged during the pilot by looking for whiteboard
tags containing ‘btpp-’.
It is also important to have consistent, shared definitions for regression
across components so triagers do not waste effort on mis-labeled bugs.
Comments?
I am posting this plan now for comment over the next week. I intend to
finalize the triage plan for implementation by Tuesday, April 5th. Feedback
and questions are welcome on the document, privately via email or IRC
(where I’m emceeaich) or on the bugmast...@mozilla.org mailing list.
Timeline
January: finish finding component responsible parties
February: pilot review of NEW bugs with four groups of components, draft
new process
Now: comment period for new process, finalize process
Q2: implement new process across all components involved in shipping Firefox
Q3: all newly triaged bugs following the new process
-- Emma Humphries, Bugmaster
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
