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

[Richard Wilbur <richard.wilbur@xxxxxxxxx>]

On Thu, 2009-09-03 at 15:51 -0400, Vikram wrote:
> Robert Collins wrote: 
> > On Mon, 2009-08-31 at 07:37 -0500, Deryck Hodge wrote:
> > 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
> >   
> I understand and acknowledge what you are trying to say, but how about
> this: change the look of the pages according to the teams a person or
> bug traige participates in. Let's say a user is a part of bug control
> team so they should allow only the people in their team see a seprate
> page that has those undecided bugs. This way not everyteam would be
> affected and the core-devs can do their job easily. What I mean is
> that create a new team or maybe edit an existing one so that the
> people subscribed to that team can see the undecided bugs page which
> would also help make their count down to zero, because it will
> increase their efficiency.
> 
What about making several (configurable?) bug views?  They could be
custom categories configurable on a project-wide or developer-specific
basis to accommodate different workflows.  These could be available from
a drop-down selection and provide bookmark-friendly URLs.  Then the
project leader is spared the extra overhead of assigning and reassigning
everyone on their team specific roles in Launchpad simply to enable
access to particular bug views as interests, capabilities, and
availabilities change.  Moreover, if I understand Robert correctly, his
workflow would specifically use three of these pages, whereas the Ubuntu
workflow would assign one of those three pages to the bug triage team.

My workflow as a developer is similar in that I want to find the oldest
or newest untriaged bugs when I wish to see alternately what is
languishing in the bug queue and what has just landed.  Preparing for a
release, I want to see what are the most vital bugs to solve before the
code freeze.

When I change hats to work as a systems analyst/integrator and consider
a package for use in a system, I tend to gauge the risks by the severity
of the outstanding bugs--especially if they predate the last release.
This also outlines the level of commitment I need to make to the project
if I choose to build the system using said package and find the
outstanding bugs adversely affect system performance.

It seems the easiest way to satisfy individual workflows is to allow
individually configurable views.

Richard