Launchpad bug workflow change

[Henrik Nilsen Omma]

Phillip Susi wrote:
> Henrik Nilsen Omma wrote:
>> I agree that 'evaluating the urgency' should also fit into the 
>> Triaged state. However, not that this can only be done by ubuntu-qa 
>> or developers (setting importance). Assigning resources can really 
>> only be done by the people who intend to fix it, which is an even 
>> smaller group. The point of having the Triaged step is that the 
>> people fixing bugs should not have to look at all 30 000 open bugs. 
>> They only look at Triaged and from that group they reject some, push 
>> some back to Incomplete and add some to their Todo list. That should 
>> make the overall workflow more precise and efficient. We can discuss 
>> how well the word 'Triaged' fit that category, but IMO we do need 
>> that category.
>
> Now it sounds like Todo is the same as In progress, set by a developer 
> when he is ( or is about to be ) working on  it.  And Triaged is for 
> bugs that are ready to be pulled into that pool, which is what 
> confirmed is today.

Todo is the list of bugs that a developer intends to work on, but it may 
take months before that work starts. In Progress should be used when 
work has actually started. It not the most frequently used state, that's 
true.

> It looks like you are trying to find a state for bugs that are 
> completely documented, but for some reason are not ready for developer 
> attention.  

There are several groups of people working with the bug list at 
different stages and with different skill sets. The system should help 
all these groups organise their work. What may at first seem like too 
many bugstates  can be useful in showing what stage the bug is at 
relative to these different groups.

What I did not mention in my first mail (just confirmed this with the LP 
developer), is that the groups who can set the different states will now 
also change.

 * When a bug is filed it will be New


The bugsquad can (actually anyone):

 * Determine whether it is Invalid, Incomplete or Confirmed (reproduced)


The bug contact, ubuntu-qa or a developer can:

 * Set the bug to Triaged if all the needed information is there AND at 
the same time give it an importance. This person can also set it to 
WonFix or push it back to one of the earlier stages such as Incomplete 
or Invalid.


A developer can:

 * Move the bug from Triaged to ToDo or push it back to a previous category.


This new structure gives several advantages.

 * By looking at the status of a bug you can immediately infer whether 
the bug has been vetted by a trusted person. In Triaged it has been seen 
by a trusted ubuntu-qa person and in ToDo by a developer.

 * Each group has a smaller group of bugs they need to look at. The 
smaller group in ubuntu-qa only has to look at the Confirmed bugs, 
provided we have an active bugsquad outside ubuntu-qa. Developers only 
have to look at Triaged, knowing these have already been looked at by 
ubuntu-qa.

 * Pushing bugs back to previous categories is a useful way to provide 
tutoring to less experienced triagers (thus helping them gain 
experience). Such push-backs should be accompanied by helpful advice on 
how to triage it correctly.

> What other reason would a developer have for not wanting to look at a 
> bug other than it is invalid ( and thus should be rejected ), or it 
> needs fixed upstream?  Maybe we just need to bring back the upstream 
> state we used to have in bugzilla?

I think this can be done by adding an upstream task and setting the 
Ubuntu task to WontFix.

Henrik