A few comments, although I think others have touched on some of this already.
I think my biggest concern is that this is conflating triage and prioritization, which complicates things and introduces ambiguity. For example, what would it even mean to have a "triage: fix-now" bug that's also a P5? I'd much rather leave prioritization to the priority field. I'm similarly dubious about the value of "not-urgent" and "wishlist". In part because those also imply priorities, but also because this phrasing seems like just kicking the can down the road on "making a decision". It would seem simpler to just have a triage +/-/? flag to indicate if a decision on triage has been made. Although we're still kind of tap-dancing around what to do with the inevitable pile of "we just won't be able to fix this soon bugs" -- I'm not sure a subtle triage flag effectively communicates intent to people that don't live inside Bugzilla like we do. It wouldn't be any worse than the status quo (and so is fine to trial), but it should really just be a new status/resolution... The existing "WONTFIX" and "INVALID" often convey the wrong meaning, a more accurate (and gentler!) "DEFERRED" or "INACTIVE" or $BIKESHED_HERE is something I'd like to see for this common condition. I don't really understand the 3-month auto-timeout of bugs back to an untriaged state. This seems like it's just creating work and makes Bugzilla annoying. Nor is a one-size-fits all solution right here -- large / long-term and small / short-term project areas will have different needs. Grooming the list of triaged, prioritized bugs is important for teams to do, and we should encourage them to do so, but starting off with this being automatic seems premature. I'm also concerned about bolting on yet more UI, which makes Bugzilla even _more_ obtuse and complicated. But given all the feedback on the current proposal, I suppose it's not worth commenting on here because I presume this would all change anyway. This also seems like it should just be a separate project. Justin 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
