Re: [Launchpad-users] new way to look at the bugs

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Mon, 2009-08-31 at 07:37 -0500, Deryck Hodge wrote:

> I commented on one of the bugs, but just to continue on list....
> 
> As Martin notes, I'm not sure the default sort should be changed to
> favor the triager.  If I'm just browsing for bugs in a another project
> would I want this new sort order?  Maybe so, but I'm not sure.  Maybe
> comments here will help us gauge interest in this.

So, I filed those bugs after realising that what I do as someone that
uses launchpad a lot, is fight the sort order, every single time I want
to assess 'the next thing to do' in a project I'm contributing to.

I want to know all my bugs have been assessed for OMG
moments[triage/confirmed]; I then want to work on blockers for the next
release, and after that general bugs. At the moment thats three
different checks :(.

There are multiple users for bug pages. I think that the primary user
role is that of developer: These are the people that look at the page
the most, after all. Its their job/passion/choice/whatever to be
fixing/analysing/working through the bug list. While an end user, and
project leader will come to these pages, the /default/ sort order does
not need to meet their needs as much as it does that of developers.
Having different sorts is a great way to meet the needs of more people.

That said, I think the sort I am promoting would fit project leaders
well, and not be unreasonable for outsiders/end users.

Now, its true that not all projects will want to categorise their bugs
at all, and others have a workflow where some developers won't want to
know about untriaged bugs at all.

For the former set, I put it to you that they won't be affected; if they
are not categorising bugs, any default sort that places all bugs at the
same 'status' together is equally good.

For the latter case, say Ubuntu, their philosophy is that core devs need
to be developing, not deciding if a bug report is actually a bug: they
don't want to see 'untriaged' bugs *at all*. This has a few problems,
chief amongst them the result that untriaged bugs are never examined by
a developer. Ubuntu are actively fighting to drive the untriaged bug
count down to zero. *If* the succeed, the number of untriaged bugs any
developer sees any any point would be modest - even project wide, modulo
spikes at release (and at that point, I think you'll want every hand on
deck to figure out which of these new reports are OMG moments, and which
are more sedate issues).

I've never heard of a workflow where bug status is managed, devs don't
want to see untriaged bugs *and* there is no goal to drive the count of
such bugs to zero.

So, I don't think we should be scared of being overwhelmed by untriaged
bugs: while thats a real possibility, its one we should be making as
simple as possible to rectify!

> I wonder, though, if just having a bug list easily re-sortable like a
> milestone list is the best way to handle these concerns?  There are
> several open bugs about sorting in addition to these two.

The sort I propose is more complex than a single column sort. If the
columns needed to sort that way, and incremental-sorting [sort on col X,
shift-click on col Y to do a subordinate sort by that, etc] was
available, it would be sufficient.

> I should note that I'm more hesitant about changing the default sort
> order of importance than the secondary sort on status.  I think the
> secondary sort being status rather than bug number is reasonable.  The
> questions for me are really around determining in what order
> importance should be sorted by default and finding a way to help
> people more easily re-sort bug lists.

+1 on being more easily able to re-sort bug lists; that shouldn't stop
us thinking about what sort we want by default :).

-Rob

Attachment: signature.asc
Description: This is a digitally signed message part