Proposed changes to workflow bug management

[Emilio Pozuelo Monfort]

Emmet Hikory wrote:
> Emilio Pozuelo Monfort wrote:
>> Scott Kitterman wrote:
>>> I'd encourage anyone with ideas on how avoiding these bugs could be added to
>>> the standard bug triage workflow in a reasonable way to discuss it on the
>>> bugsquad mailing list.  Perhaps there's another way that'll be effective for
>>> them that doesn't impact to extensively on the existing workflow.
>> I proposed before UDS to assign these workflow bugs to teams (e.g.
>> ubuntu-archive for confirmed syncs, ubuntu-{universe,main}-sponsors for
>> sponsorship requests, ubuntu-mir for MIR reports...
>>
>> I was told bugsquad list of bugs exclude bugs with an assignee (and bugs with
>> status >= In Progress), so if that's true, this might be a good way. I
>> personally don't like the idea of making them private...
>>
>> What does people (specially those in affected teams like ubuntu-archive) think
>> about this approach?
> 
>     I have three objections to this approach, as follows:
> 
> 1)  It is not always the related team that is responsible for the next
> action for these bugs, and in cases where more information is
> requested, not always the last person to work on the bug who ought
> respond.

In those cases you can reassign to who needs to provide that info and set to
incomplete, and then the bug will disappear from the team list.

> 
> 2)  As assignment is typically used to indicate "I'm working on this",
> this use of assignment may create the false impression that things are
> in progress which nobody is tracking closely, or for which nobody
> feels specific responsibility, and so are available as general work
> items.

If it's not "In progress", nobody is working on it. If people thinks the fact
that a bug is assigned to somebody means he's working on it, they need to stop
thinking like that because that's wrong.

> 3)  Due to the way in which launchpad works, notification for
> assignees is very different than notification for subscribers.  As a
> result, such a change further impacts the workflows and teams, and may
> require the creation of supporting mailing lists, etc. in order to
> ensure that team members are receiving mail appropriately.

I talked about this with Sarah and reported bug 229628, but it was working
correctly. If there's more issues, they should be reported and fixed, but there
aren't AFAIK.



Anyway, if this isn't a good approach, let's not use it, that's fine with me.
But hiding the processes because new contributors may touch them isn't
appropriate IMHO.

If somebody touches them when he shouldn't, tell him, and move on. Personally
I've never got more than a few mails from people changing things to wishlist,
and given the volume of mail I receive that's totally manageable.

Cheers,
Emilio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20080527/ab9ae241/attachment.pgp