Proposed changes to workflow bug management

[Ben Collins]

On Tue, 2008-05-27 at 16:18 +0200, Reinhard Tartler wrote:
> Ben Collins <ben.collins at canonical.com> writes:
> 
> > Take the intrepid linux-ports package that will be coming down the pipe.
> > The bugs will be split up on the basis of architecture. So assigning
> > bugs to the ubuntu-{powerpc,ia64,hppa,sparc} teams as a triage step
> > makes sense, and immediately shows responsibility. Then individuals in
> > those teams can take the bug.
> >
> > No one has yet explained a better way to handle this sort of workflow,
> 
> Obvious way: don't assign, but subscribe the team that is going to
> handle the bug.
> 
> The advantages:
>  - it does not give users the false impression someone would actually
>    work on that bug

I don't see how users get that impression. In-Progress is what is meant
to show that a bug is being worked on. Assignment just shows who is
ultimately responsible for the next stage of the workflow. Once it is
triaged, in the case I outlined, then a team is responsible for the next
step (not a single person). That next step is deciding whether it should
be fixed or not, and then having a person work on it.

I also disagree that assigning to a team means that no one feels
responsible for it. In fact, the alternative for the above situation is
to assign to no one, which means no one need even bother look at it. The
workflow I suggest, assigning to a team, leaves the team feeling
responsible, and is a good way for new persons in the team to get their
hands dirty (look for bugs assigned to the team).

>  - several teams can be subscribed, which is not possible with
>    assignments.

Subscriptions to me are more of a list-of-interested parties. In no way
do they describe or show responsibility.

> Downsides:
> 
>  - subscriptions are not as exposed as assignments in the UI and perhaps
>    a bit more difficult to use.

And this is ultimately what makes sub's vs. assignee useless for this
type of work flow. New volunteers to a team will need things to be more
visible to them than seasoned bug workers and developers.

My method caters to these new people (which are extremely important for
bug triaging), while the alternative caters to people in-the-know, just
so we can get rid of a feature that has been successfully used going on
two years now.

All of the suggestions so far are just replacing a well known abuse with
a lesser known abuse. Let's replace it with functionality that is suited
to the problem instead, before getting rid of it.

Another alternative, at least for my concern, is to be able to target
bugs to a specific architecture or architectures. This way, one can
easily perform search for the architecture they are interested in,
regardless of the assignee. But I suspect launchpad developers expect
people to use tags for that (which for me are useless, because they are
arbitrary and we have no way to discourage things like "ppc" vs.
"powerpc").