Components that feed into FFx, so that's Core, Toolbox, Firefox, Fennec and the pieces of platform we're using to ship.
While there's not a 'Gecko' component in bugzilla, it does cover the components there which are Gecko. -- Emma On Tue, Mar 29, 2016 at 3:16 PM, Eric Rescorla <e...@rtfm.com> wrote: > 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
