The plan to fix bug triage.... - Chromium-dev

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion The plan to fix bug triage....
Received-SPF: pass (google.com: domain of lafo...@google.com designates 172.25.149.8 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=google.com; s=beta;
        h=mime-version:from:date:message-id:subject:to:content-type;
        b=n1GO+rYv7hva1w9XnrqGLuoV15qXR7mw4AHWBFdLmlMNXMRVf3jmnXTOWhMgbWfcmP
         xUItRNIKXxAmMvh32MXw==
MIME-Version: 1.0
From: Anthony LaForge <lafo...@google.com>
Date: Wed, 9 Mar 2011 11:53:11 -0800
Message-ID: <AANLkTiku9O0tLCzaqSf+mbSxUqr1y87Akp2RNQyg4...@mail.gmail.com>
Subject: The plan to fix bug triage....
To: chromium-dev <chromium-...@chromium.org>
Content-Type: multipart/alternative; boundary=0016e68ee9a251bdd0049e12156f

--0016e68ee9a251bdd0049e12156f
Content-Type: text/plain; charset=ISO-8859-1

Howdy folks,

After spending the last few days pouring over stats/mining data from the
issue tracker, some trouble spots emerged that seem reasonably actionable.
 Before we jump into AIs, some interesting metrics to keep in mind:


   - 50% (3,902) of our Mstone-X bugs are unclassified, as are 59% (13,161)
   open bugs (i.e. no Feature|Internals|Webkit|Area-Compat-*)
      - *Lesson:* We need to be more aggressive about classification.

      - 36% (7707) of the open bugs were filed over a year ago, of those 40%
   are Available, 36% Unconfirmed, 16% Assigned, 8% Other
      - Lesson: We potentially overuse the Available label, and need to hit
      harder on Unconfirmed

      - Only 20% of the Fixed bugs were ever in an Available state (i.e.
   that's an abnormal path to getting fixed)
      - *Lesson:* Marking a bug Available isn't a great way to get it fixed
      (this could be discoverability problem since half the bugs
aren't classified
      and the right people aren't on cc)

      - ~30% of all open bugs haven't been commented on by anyone in the
   last 6 months
      - *Lesson:* We are tracking things no one cares about

      - Only 38% of the open bugs have been commented on by committers in
   the last 6 months
      - *Lesson: *We are not paying attention to 62% of the bugs.

*With that in mind, this is the approach that I'm going to carry forward:*

   - Phase 1: Fix the discoverability/ triage@ scale problem
      - Clean the label namespace and move things around
      - Assign label owners groups to each label
      - Ensure Auto-CC rules are established for each label (ideally
      pointing to groups)
         - We need to push the GA+ conversion

         - Phase 2 : Establish a front-line triage system (aka stem the
   tide)
      - We need to at least ensure that issues are getting properly
      classified as the come in/ get filed
         - New bug creation page wizard
         - Manually triage the remaining issues (Experiment w/ ChromeTurk)

         - Phase 3 (chrome-team): Classify the backlog
      - We need to classify the backlog (a one time fixit event should kill
      this) so people can find the bugs they need to work on
      - ChromeTurk might be the answer here

      - Phase 3 (chrome-pmo): Cull the backlog
      - We need to reduce the work that's in scope to things we are actually
      looking at
         - Anything with an Mstone-* label should be considered near term
         work
         - We should automatically remove Mstone-* labels from things that
         aren't being worked on (i.e. no dev activity in the last 180 days)
      - We should be aggressive about saying WontFix and not placating.

Kind Regards,

Anthony Laforge
Technical Program Manager
Mountain View, CA

--0016e68ee9a251bdd0049e12156f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Howdy folks,<div><br></div><div>After spending the last few days pouring ov=
er stats/mining data from the issue tracker, some trouble spots emerged tha=
t seem reasonably actionable. =A0Before we jump into AIs, some interesting =
metrics to keep in mind:</div>

<div><br></div><div><ul><li>50% (3,902) of our Mstone-X bugs are unclassifi=
ed, as are 59% (13,161) open bugs (i.e. no Feature|Internals|Webkit|Area-Co=
mpat-*)</li><ul><li><b>Lesson:</b>=A0We need to be more aggressive about cl=
assification.<br>

<br></li></ul><li>36% (7707) of the open bugs were filed over a year ago, o=
f those 40% are Available, 36% Unconfirmed, 16% Assigned, 8% Other</li><ul>=
<li>Lesson: We potentially overuse the Available label, and need to hit har=
der on Unconfirmed<br>

<br></li></ul><li>Only 20% of the Fixed bugs were ever in an Available stat=
e (i.e. that&#39;s an abnormal path to getting fixed)</li><ul><li><b>Lesson=
:</b>=A0Marking a bug Available isn&#39;t a great way to get it fixed (this=
 could be=A0discoverability=A0problem since half the bugs aren&#39;t classi=
fied and the right people aren&#39;t on cc)<br>

<br></li></ul><li>~30% of all open bugs haven&#39;t been commented on by an=
yone in the last 6 months</li><ul><li><b>Lesson:</b>=A0We are tracking thin=
gs no one cares about<br><br></li></ul><li>Only 38% of the open bugs have b=
een commented on by committers in the last 6 months</li>

<ul><li><b>Lesson:=A0</b>We are not paying attention to 62% of the bugs.</l=
i></ul></ul></div><div><b>With that in mind, this is the approach that I&#3=
9;m going to carry forward:</b></div><div><ul><li>Phase 1: Fix the discover=
ability/ triage@ scale problem</li>

<ul><li>Clean the label namespace and move things around</li><li>Assign lab=
el owners groups to each label</li><li>Ensure Auto-CC rules are established=
 for each label (ideally pointing to groups)</li><ul><li>We need to push th=
e GA+ conversion<br>

<br></li></ul></ul><li>Phase 2 : Establish a front-line triage system (aka =
stem the tide)</li><ul><li>We need to at least ensure that issues are getti=
ng properly classified as the come in/ get filed</li><ul><li>New bug creati=
on page wizard</li>

<li>Manually triage the remaining issues (Experiment w/ ChromeTurk)<br><br>=
</li></ul></ul><li>Phase 3 (chrome-team): Classify the backlog</li><ul><li>=
We need to classify the backlog (a one time fixit event should kill this) s=
o people can find the bugs they need to work on</li>

<li>ChromeTurk might be the answer here<br><br></li></ul><li>Phase 3 (chrom=
e-pmo): Cull the backlog</li><ul><li>We need to reduce the work that&#39;s =
in scope to things we are actually looking at</li><ul><li>Anything with an =
Mstone-* label should be considered near term work</li>

<li>We should automatically remove Mstone-* labels from things that aren&#3=
9;t being worked on (i.e. no dev activity in the last 180 days)</li></ul><l=
i>We should be aggressive about saying WontFix and not placating.</li>
</ul>
</ul></div>Kind Regards,<br><br>Anthony Laforge<br>Technical Program Manage=
r<br>Mountain View, CA<br>

--0016e68ee9a251bdd0049e12156f--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
