You might be able to create views into these triage queue's with
combinations of existing keywords and maybe a few added ones. For example:
Can reproduce
Can others reproduce the problem described?
has the inverse represented by needs-testcase for example. In the case of
the bug that needed nurturing people like alice white descend on piles of
bugs that need test cases, to then find regression ranges and and apply
techniques to build test cases. We need to re-enforce that kind of process
and maybe give people like that another keyword like "has-testcase" so
engineers with domain knowledge can descend on that set of bugs.
Then
Why it's important
What makes this problem important or urgent to fix?
combinations of keywords like "regression", "losing-users",
"sec-[critial/high] and other keywords plus some consistent priority
setting could offer good summations of different categories of important
bugs to stay on top of.
With constant triage its now possible to find good piles of bugs that have
test cases, are regressions, have been determined to be critical and are
"assigned to nob...@mozilla.org" then with these its possible to reset
organizational priorities and individual assignments. All that happens
but in clumsy ways. A good first step is to take dbaron's list of things
that need to be understood, see of we have existing markings that represent
or would help lead to understanding those aspects and formalize a bit of
process around that. The regression keyword is one that get pretty good
use, but it still doesn't reflect the kinds of ways in which regressions
have been determined to be critical or are ok with just ignoring or pushing
out to some future date or never. The platform triage is very focused on
trying to do just that.
-chofmann
On Thu, Apr 7, 2016 at 3:22 PM, Emma Humphries <e...@mozilla.com> wrote:
> 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)
>>
>
>
> _______________________________________________
> 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
