Proposed changes to workflow bug management

[Ben Collins]

On Sun, 2008-06-01 at 20:17 -0300, Christian Robottom Reis wrote:
> > I still think it's useful to have this feature. I don't see why
> > assigning a bug to a team as part of workflow is so difficult to
> > understand as a concept.
> 
> Well, you have a use case which implies it's useful, but that view is at
> odds with that assignment means in Launchpad -- and in fact, to most
> people that look at such bugs.
> 
> It doesn't actually mean anything to assign a task to a team, in the
> strict sense of assignment that Launchpad implies. There is nobody
> responsible for it, and in fact, bugs can linger in the assigned state
> before anybody has actually set it to Triaged (meaning it might not even
> be a bug) and also well after that. Users get confused with the assignee
> being set when in fact nobody is actually committed to fixing that bug.
> It's unclear who to talk to to get information on progress.

I don't see that as being true. First off, it's not assigned to the team
until it is triaged and secondly, before it is triaged, it can be
assigned to the triager.

Also, when it is assigned to a team, the entire team is responsible for
bringing it to the next step, and contacting the team is as easy as
contacting a single person (thanks to launchpad :).

So I understand the problem you have with the feature itself, but the
way we use it isn't depending on the problems themselves.

> I get the feeling that team assignment is used to produce a list of bugs
> to work off from. I also think it's used mainly because of shortcomings
> in the bug tags feature. If you tagged x86 bugs with an x86 tag and it
> stuck, it would have the same effect of putting a bug on a list that
> could then be looked at by a separate team -- all you'd need to do is
> update bookmarks.

Having a list of bugs to work from is the loose sense of the reason it
is being used. The real use is to be able to separate responsibilities
within a single package. A large package such as the linux kernel cannot
have a single point of responsibility, and thus, not a single point to
assign it to, unless we can break it down into teams. This is moot for
intrepid and beyond, but I can see this being a reoccurring use case, so
it might as well get resolved.

I believe I've stated to the LP team once or twice in the past, that
being able to control the tags associated to a particular package would
make this easy to do without assigning to a team (would also make tags
much more useful), but something with more visibility would be best.