launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Sat, Jan 8, 2011 at 8:13 AM, Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx> wrote:
> On Thu, 2011-01-06 at 17:41 +1300, Robert Collins wrote:
>>  * the high bucket to be about 6 months deep - many parts of Canonical
>> are on a 6-month cycle and fitting in with that is convenient
>
> How deep is the High queue? We close about 540 high and critical bugs in
> 6 months, but we current have 801 high and critical bugs. Most of those
> bugs were reported and closed in 30 days. I think this means the High
> queue should be between 450 and 540 bugs. We have more than a 9-month
> backlog.
>
> 10% of closed High are older than 90 days. We are going to close about
> 54 bugs High bugs that are before October of last year in the next 6
> months. I ask again. Are old bugs bugs that marked High really High?

A bug review will help with that; so will having more time on bugs. We
should not consider feature bugs - ones that will be handled by the 3
feature squads - when considering how deep the bug queue is.
>
> Please do not set any bug to triaged unless it also has an importance
> set.

The rules would not do that, however for clarity I've added in 'what
is bug triage' a statement:
     When we have triaged a bug, it has status '''triaged''' and an
importance other than '''unknown'''.

> I tend to mark bugs relating to a feature in development as High, but
> when I discover that we are not willing to fit the issue to a milestone
> after a month or two, I downgrade it.
>
> I mark feature requests/enhancements as low.

I think those are reasonable heuristics assuming that they are things
> 1-2 days of effort; things below that fall into the interrupt-queue
(though I'm not sure anyone knows quite where we should draw the line
yet). For things in the interrupt queue, a small feature request may
well be a great idea, have a wonderful positive effect on the system
and be reasonably triaged high. I dunno - I guess I just think we need
room to consider things we hadn't planned on as important.

> I am conflicted about trivial bugs (bugs that can be fixed in 1 or 2
> hours or work). Most do not prevent someone from completing their task,
> but these items that frustrate user as the bug ages. Maybe I should
> never let users know the bug is easy to fix. While I rarely mark these
> bugs high, once I see enough to consume a day, I arrange for them to be
> fixed.

I think its fine to mark such things high if you think they have a
significant impact on our users / our perceived quality / our
usefulness.

-Rob