On Tue, Apr 5, 2016 at 9:27 PM, Emma Humphries <e...@mozilla.com> wrote:
> It's been a week since I asked for your comments on the plan for triage, > thank you. > > I'm going reply to some general comments on the plan, and outline next > steps. > > Ekt and others said that up to now, individual teams have owned how they > triage and prioritized bugs. Mozilla has made commitments to how we are > going to follow up with people filing bugs. > Where were those commitments made? Can you send a link? The bulk of bugs in Firefox-related components are P3, most likely because > we have a bug filing form that defaults to P3 and that needs to be fixed if > it's still in use. > > Having to make what seemed like snap-decisions on bugs was also a point of > concern, but that's something the proposal had a work around for, using > needinfo? to defer a triage decision on a bug until enough questions were > answered. And since we made a commitment to make decisions on bugs, we need > back pressure on untriaged bugs. > > But from what I read, y'all are amenable to standardizing the priority > flag's use in Triage > I don't think this is a question of which *flag* to use so much as whether it's useful to produce a new flat taxonomy which is redundant with the existing priority mechanisms that teams are using, which in many cases are richer than a three-level (now, soon, no-plan) hierarchy as you propose. I think the fundamental problem here is that you're trying to design something that might be useful for defects but isn't useful for a large fraction of bugs which are actually a method of documenting planned new work. Bug Bugzilla needs to work for all of these. -Ekr In addition, I'll want to remove several fields which are not useful, or > superfluous from the bug entry wizards. Priority is a field that should be > set by people triaging bugs, not entering them. We have a keyword > vocabulary which is more expressive than severity. And our bug entry forms > don't show the version affected, or the STR (steps to reproduce) flags > which means it's an extra edit to get the information relman needs into a > bug. > > Thank you again for your time and consideration as we make Bugzilla and > Firefox better for everyone. > > -- Emma Humphries > > > 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
