First: there's that Bugzilla Anthropology project ( https://wiki.mozilla.org/Bugzilla_Anthropology) thanks. I'd heard mention of it and asked around.
What we found during the pilot, and the Platform Team has found in their triage, is that list of bugs with needinfo? is I'm worried that multiple queues in a component would be adding complexity, but this is something I'm willing experiment with. I don't think that picking a component or group of components we could try that style of triage on would block implementing the Triaged:Yes|No flag and UX improvements in Bugzilla. Would you be up for helping me run a short pilot of the multi-queue system you're describing? -- Emma On Wed, Apr 6, 2016 at 11:50 PM, L. David Baron <dba...@dbaron.org> wrote: > On Wednesday 2016-04-06 18:47 -0700, Emma Humphries 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 > > > > On Tue, Mar 29, 2016 at 1:07 PM, Emma Humphries <e...@mozilla.com> > wrote: > > >> Today Iโm asking for feedback on the plan which is posted at: > > >> > > >> > > >> > https://docs.google.com/document/d/1FFrtS0u6gNBE1mxsGJA9JLseJ_U6tW-1NJvHMq551ko > > I'm assuming the above URL represents the current proposal, although > given the "draft second proposal" wording above, I'm not sure if > that's the case. > > > I don't think the idea that a bug belongs in the triage queue if it > is untriaged and without a needinfo? is the right process. I think, > instead, that there should be less emphasis on needinfo? to a > specific person, and more emphasis on grouping bugs into a small > number of categories of information that is needed, and allowing > people to triage those separate queues. > > Explaining why I think that requires a little bit of a digression: > > There are a number of separate things we want to understand in a bug > report, as I described in http://dbaron.org/log/20120816-bug-system : > > Understand description > Do the developers or triagers reading the bug understand > what the reporter is saying? > > Agree it's a bug > Do the module owners or peers or other authority agree that > the problem is a bug? > > Can reproduce > Can others reproduce the problem described? > > Why it's important > What makes this problem important or urgent to fix? > > How to fix > What should be done to fix the problem? > > (I'd much rather a bug report be editable text, with history > available, for answers to these or similar questions -- rather than > a stream of permanent comments. But we seem stuck with the horrid > stream-of-comments Bugzilla format, which means I try to ignore the > comments as much as I can. Then again, a 200 character summary is > often good enough to answer the above 5 questions. As with the rest > of the Internet, don't read the comments.) > > Determining answers to any or all of the above might require > multiple rounds of dialog, and some of them need to be understood in > sequence rather than in parallel. They also require very different > sets of expertise to determine. (Some of them require people with a > bit of domain knowledge; some require detailed knowledge of relevant > specifications.) But they also don't require expertise from one > person in particular, so needinfo? is not generally appropriate. So > the idea that bugs are in a queue unless they have a needinfo? seems > wrong to me; I think a good triage process should involve queues > representing the type of knowledge that's needed, rather than queues > for a particular person to answer -- and people should be able to > triage those queues (e.g., bugs that are untriaged because they lack > information that allows others to reproduce, bugs that are untriaged > because they require an expert in the relevant standard to decide > whether our current behavior is correct or not -- state that could > also be reflected in the bug) or the general queue of > next-step-unknown bugs. > > While we can't get very far at all if we don't understand the > description, it's often hard to make a decision about the priority > until we understand how many users are affected (which sometimes > requires the ability to reproduce), and about whether the bug > described is actually a bug at all. (Though there are also many > cases where we can make decisions about the priority without some of > these pieces of information.) These are things that might be most > efficiently determined by different people acting as part of the > triage process, but the people aren't specific enough that needinfo? > is the right tool. > > -David > > -- > ๐ L. David Baron http://dbaron.org/ ๐ > ๐ข Mozilla https://www.mozilla.org/ ๐ > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. > - Robert Frost, Mending Wall (1914) > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
