I'm trying to figure out the scope of this proposal. Are you expecting it to apply merely to Firefox or to Gecko as well?
-Ekr On Tue, Mar 29, 2016 at 1:07 PM, Emma Humphries <e...@mozilla.com> 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 > > _______________________________________________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
