Sorry to be dense, but if I understand correctly, you'd like to: 1. Have a policy that all of Gecko needs to triage bugs in a certain way. 2. Redefine how everyone defines priorities?
And you think that 24 hours is enough time to get consensus on that. Do I have that right? -Ekr On Wed, Apr 6, 2016 at 10:47 PM, Emma Humphries <e...@mozilla.com> wrote: > Following up on yesterday's email: I put together a draft second proposal > and shopped it around some, and now I want to bring that back into the main > discussion. > > The bullet point version of this is: > > * Add a binary field that components can use, TRIAGED (Y/N, T/F, +,-) > * In the case of Firefox related components, have a consistent definition > of P1-P5 and make sure that triaged bugs have a Priority assigned > > This has a couple of implications: > > This means I have to have a plan in place for dealing with Priority going > from ad-hoc to one set of meanings for bugs in Firefox components. > > If any of you have worked with longitudinal social sciences data sets, > this is a common thing. Values for fields change over time, and researcher > consult documentation so that code consuming the data would work with the > discontinuities. Some of this can be handled through bugzilla UI, so that > components using the TRIAGED flag would display the description > corresponding to P1-P5 and other components would not. > > We also need to go through all the existing whiteboard, keywords, and > custom flags we are using for e10s and other projects that are being used > to indicate importance. > > I'd like to finish up feedback on by the end of the working day Thursday > the 6th (PST.) > Then we'll get to work on a solid specification for the work so we can > start implementation sometime in Q2. > > Thanks. > > -- Emma > > On Tue, Apr 5, 2016 at 5: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. Thus we need consistent >> decisions across all the components that go into Firefox about bugs that we >> can share back to non-Mozillans on bugs they file, so that we can get them >> to contribute more high-quality bugs, and participate in other efforts in >> support of the project and the Open Web. I'm aware I'm asking teams with >> existing process to make a change, but it's for a global gain. >> >> Several people pointed out all the fields in Bugzilla that have and could >> be used to manage priorities, such as priority and rank. But we don't use >> the priority field consistently across the project. I've asked for teams to >> document how they use Priority, >> https://wiki.mozilla.org/Bugmasters/Projects/Folk_Knowledge/Priority_Field, >> and you'll see how that varies. >> >> When I checked how the Priority field was used in Firefox-related >> components, that distribution was: >> >> --- 460,362 >> P1 14,304 >> P2 15,971 >> P3 37,933 >> P4 4,204 >> P5 2,913 >> >> 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. Doing that would create a discontinuity in historical >> data, but that's not an insurmountable problem, and we can document that >> breakage for researchers using historical data. >> >> So next step is a second proposal, simplified, using Priority to >> represent triage decisions. >> >> 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
