bug lists - undecided complete bugs should sort above critical

[Robert Collins]

In terms of triage, moving undecided bugs forward is very important:
they might be critical. So for a developer looking at the bug list with
the default sort, they should see:

undecided new/triaged/confirmed/inprogress/fix*/incomplete-with-response
critical *
high *
medium *
low *
wishlist *
undecided incomplete-without-response

As this reflects the appropriate order to look at bugs next. (Deciding
on the importance of an undecided *but complete* bug should be pretty
easy).

Having undecided complete bugs at the bottom of the list is a starvation
issue, unless developers consciously think about this and fiddle the
sort orders.

 affects malone

-Rob

[Vikram Dhillon (dhillon-v10)]

Well, this is true in the aspect that the undecided bugs could be critical but there is a problem, there are so many of them that we can't look through all of them, but I am working on a script that can identify complete or incomplete bugs and then mark the incomplete ones as invalid. We will see how that goes...

[Robert Collins (lifeless)]

On Fri, 2009-08-28 at 22:01 +0000, Vikram wrote:
> Well, this is true in the aspect that the undecided bugs could be
> critical but there is a problem, there are so many of them that we can't
> look through all of them, but I am working on a script that can identify
> complete or incomplete bugs and then mark the incomplete ones as
> invalid. We will see how that goes...

I agree that its a challenge for Ubuntu specifically to deal with huge
numbers of bugs where the importance is not quanitified for various
reasons; however I think making it easier to present those to triagers
will go some way to making it more obvious and require less
documentation reading/remembering.

You've marked this bug as in-progress but not assigned it to yourself?
Are you planning on making the change to malone that I proposed?

-Rob

[Vikram Dhillon (dhillon-v10)]

Oh, sorry I forgot about that, thanks for posting that though, you see I am not a leader of any team, I am a developer so I will try to the best of my ability to make this happen and see how it goes

Thanks

[Martin Pool (mbp)]

If there was at least an optional link to get this, that would be useful, even if it's not the default.

This needs to be done with some sensitivity because if I'm looking at some other project's bugs where I can't reprioritize them it's hardly useful to give me the unprioritized bugs first.

Not all projects will drive unclassified bugs to zero as a priority. Some might just rely on reading the mail.

[Deryck Hodge (deryck)]

Like Martin says, I'm not sure about this as the default, but a way to easily get to this view of bugs would be nice. Would having the bug list table sortable like milestones be sufficient (assuming we don't do this as the default sort)? There are other bugs open about sorting, which should be considered as well.

Also, I'm certainly open to review patches for this (if Vikram or others are working on this). And maybe I would feel differently about it as a default if looking at a working example.

[Martin Pool (mbp)]

One way to tackle this stepwise would be to add some role-oriented
options into the search dropdown and/or into the portlets

 * sort for triage - puts undecided bugs first, then new bugs
 * sort for completion - put inprogress bugs first

I actually think if you're operating in one of these modes (and
they're probably good focussed ways to operate) you may want to see
only bugs of that kind, and just having quick links from the portlet
currently called "filters" would be best. One for inprogress and one
for undecided importance would be good, also one for "assigned to
anyone" as the inverse of assigned. I may already have a bug on that.

--
Martin <http://launchpad.net/~mbp/>