Re: Triage Plan for Firefox Components

On Tue, Apr 5, 2016 at 9:27 PM, Emma Humphries <[email protected]> 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 <[email protected]> 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 [email protected] 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
> [email protected]
> https://mail.mozilla.org/listinfo/firefox-dev
>
>

_______________________________________________
firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/firefox-dev