<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 4/6/2016 9:17 AM, Eric Rescorla
wrote:<br>
</div>
<blockquote
cite="mid:CABcZeBOjnk7OKcofT=aktYUvXJ4KukUdOxSAE1HaiUWA_fCdRw@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
We believe that the *minimum* kinds of triage and response are the
ones that Emma outlined originally:<br>
<ul>
<li>fix-now (typically only used for defects, and tracked very
closely by our quality teams and release management)</li>
<li>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.<br>
</li>
<li>no commitment (name TBD): we expect that most non-defect bugs
would go into this category<br>
</li>
</ul>
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.<br>
<br>
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.<br>
<br>
--BDS<br>
</body>
</html>