launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

On 11-08-19 03:31 PM, Aaron Bentley wrote:
>> > One source of confusion here is the "critical" name.
> Let's change the critical name, then.  It's not just confusing to us,
> it's misleading to outsiders who look at our bug lists.  We're not using
> Medium, so let's move our High bugs to Medium, our Critical bugs to
> High, and reserve critical for things that actually are critical.  (And
> update our policies accordingly)


Like I said in the past, I'm not opposed to this. If I recall correctly,
I thought at the time that the issue would be moot in a couple of
months, and that was the main reason not to do it. Seems like the issue
isn't moot.

If a lot of people think it would make the situation clearer, then let's
do this.

> 
>> > Think of it as 'Work-on-first' bucket which is what they are about.
> And since Critical doesn't mean "must be fixed now" why is it a
> work-on-first bucket?  Why do we have a focus on burning it down to
> zero, at the cost of stalling our high and low bugs?  It seems like
> allowing us to fix high bugs could improve the overall user experience more.

Because we (at least I) think these issues are more important than other
High or Low ones. Quoting Gavin who did a good job of summarizing the
criteria here:

> https://dev.launchpad.net/BugTriage defines Critical bugs as:
> 
>   ...those that need attention before all others. Right now: OOPSes,
>   timeouts, regressions, stakeholder-escalated bugs, production issues
>   and build breakage.
> 
> Breaking that down:
> 
> - Stakeholder-escalated bugs, no arguments.
> 
> - Regressions are critical, no arguments. Get them fixed now before
>   then end up costing even more.
> 
> - Production issues and build breakage are definitely critical to
>   Launchpad's viability.
> 
> - OOPSes are sometimes critical, but we always call them critical
>   because we want to have zero OOPSes.
> 
> - Time-outs are not always critical, but again we always call them
>   critical because they're (a) OOPSes and (b) we want to drive them
>   towards zero. Doing this has also pleased the users more than almost
>   anything else, and pleasing users is good.

I don't see any problem with that list as it is.

My main concern at this time is the fact that we are getting since April
1st 20 new of these bugs per week [1]! Which is about the same number of
issues we fix on average per week [2]. No wonder the burndown is stalled
for so long.

I don't have an explanation of why we are finding each weeks 20 of these
issues. I also don't have the impression that these are "legacy" issues.
Many of them comes from new work. We need to investigate that stream of
incoming rework and stop it at the source if we ever hope to burn these
issues down. Once I sort out the recruitment projects I'm working on,
that's my next project.

Cheers

[1]
https://lpstats.canonical.com/graphs/LPProjectCriticalFiled/20110401/20110820/
[2]
https://lpstats.canonical.com/graphs/LPProjectCriticalClosed/20110401/20110820/

-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: OpenPGP digital signature