launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Fri, Apr 15, 2011 at 2:48 AM, Francis J. Lacoste
<francis.lacoste@xxxxxxxxxxxxx> wrote:
> Hi Robert,
>
> Squads were currently doing triaging by looking at the New bugs queue on
> Launchpad.
>
> https://bugs.launchpad.net/launchpad-project/+bugs?field.status:list=NEW
>
> This is also the number tracked by
> https://lpstats.canonical.com/graphs/LPProjectBugTriage/
>
> We are doing an ok job there.
>
> But on https://dev.launchpad.net/BugTriage, two different links are listed
> there as the ones to use for triage.
>
>  * list of all Undecided/Unknown bugs: http://bit.ly/f3LO8f
>  * list of all Untriaged bugs: http://bit.ly/eRjI8t

Right, this is because LP models untriaged in two ways:

> I think these two links are not good because they include INCOMPLETE bugs that
> didn't receive a response. This means that these are lists that the triager
> cannot burn to zero. Which means that day-in-day-ou, they'll have to look at
> the same tickets which leads to a very poor experience.

Actually, incomplete bugs are meant to expire - bug 760950 - is the
thing curtis found overnight where the expiry system was:
 - failing
 - failing to report that it was failing

> I think the right thing to monitor is the list of NEW, CONFIRMED, TRIAGED and
> INCOMPLETE_WITH_RESPONSE bugs that have an Undecided/Unknown priority.
>
>  * http://bit.ly/dWg2sw
>
> I think this is a list that a triager can actually burn down.
>
> From the sets of the two previous lists, it excludes, INCOMPLETE bugs that
> didn't receive a response as well as bugs that had an importance assigned but
> that aren't marked as triaged. In a way, I don't think that list is a big
> deal, since Importance has been properly set. Maybe those could be look into a
> secondary list. But it's less important.
>
> Unless you disagree, I'll update BugTriage and MaintenanceRotation schedule
> with my proposed link.

I'm not sure if I agree or disagree :) - I think the key things are:
 - every bug should be touched just enough to decide if its critical/high
 - it should be easy to query or sort our triaged bugs
 - our main web UI should not tell other folk we haven't been triaging
(and leaving a bug as e.g. 'high with status new' would leave a count
marker in the progress bar)

I agree about with dropping INCOMPLETE_WITHOUT_RESPONSE which we can
do very easy from both searches... though I'll note that once we fix
bug expiry it will shrink that apparent backlog very quickly.

What do you think?

-Rob