Re: Triage Plan for Firefox Components

On 4/6/2016 9:17 AM, Eric Rescorla wrote:
>
>
> 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.

It is true that a large part of this program is focused on defects. I am 
sponsoring and driving this as part of our larger quality initiative, 
because we have serial problems of not noticing or reacting properly to 
critical defects.

We are also approaching this from the perspective of community 
involvement. Making a clear decision about every bug has been identified 
as a critical component of retaining and building our community of 
testers, including our prerelease population.

We know that many bugs are misfiled, so simply limiting the scope of 
triage to defects without making sure that things aren't misfiled will 
leave significant gaps. From a community perspective, it's also 
tremendously valuable to make a clear and rapid response to non-defect 
(feature) requests.

We believe that the *minimum* kinds of triage and response are the ones 
that Emma outlined originally:

  * fix-now (typically only used for defects, and tracked very closely
    by our quality teams and release management)
  * fix-soon (the team is making a time-boxed commitment to this
    defect). We picked three months as the standard time-box because we
    see that most teams cannot manage a backlog larger than that
    effectively. Some teams may not use this triage state much, or at
    all, but it's the kind of category that we want to see used for
    serious but not blocking bugs, common randomorange test bugs, and
    other bugs where we want to express a cross-team or external
    commitment to work on something.
  * no commitment (name TBD): we expect that most non-defect bugs would
    go into this category

Some teams have more detailed triage and categorization systems, and it 
is the intent of this program to support those per-team workflows. But 
at a minimum we need a shared decision and communication framework which 
will work across all our teams, no matter their workflow. We believe 
that this basic system will support many different teams, whether they 
are using quarterly/yearly planning systems, or more agile systems like 
iterations or kanban-style backlogs.

I'll also note that the communication aspect of this extends beyond the 
original act of triage. An important part of this triage plan is the 
changes to the BMO display of bug state. Currently a lot of the 
important metadata about a bug is "hidden" behind tracking and status 
flags, the undocumented priority flag, and keywords which are rarely 
self-documenting. Emma is arranging for the metadata to be translated 
into a human-readable English summary so that people who are not deeply 
familiar with release tracking and per-team workflow can still have a 
confident sense of the state and decisions made about a bug.

--BDS

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