Launchpad bug workflow change

[Henrik Nilsen Omma]

Jordan Mantha wrote:
>>
>> If we want a certain group of people who write code but are not MOTU or 
>> core-dev to be able to set the whole range of status settings then we 
>> can set up a team that gives that access. I agree that people can write 
>> valuable code without doing .deb packaging for example.
>>     
>
> OK, but it wasn't so much the new status fields that has people concerned
> as changing who can set the status like:
>
> "A developer can:
>   * Move the bug from Triaged to ToDo or push it back to a previous category. "
>
> Why should only a person in ubuntu-dev be able to use ToDo? Other people
> need to be able to set ToDo, In Progress, Fix Commited, and Fix Released. 
>   

Yes I can see how that becomes a sensitive change, I also happen to 
think it's useful. I don't agree that someone working by themselves, 
outside of the ubuntu structures, should be able to set the state to In 
Progress (or the new ToDo) because that implies a promise to the 
submitter that a fix _in Ubuntu_ is in the works and that promise can 
really only be made by someone with upload rights.

If you have to get a change sponsored you can also notify the potential 
sponsor ahead of time and ask for a state to be set. That way the 
responsible sponsor is aware of the work and duplication can be avoided. 
If I file an RFE for an unlikely change to Ubuntu and someone who can 
code and agrees with me might go ahead and start coding, setting the 
status to In Progress, but that change will not likely be accepted when 
it comes time to sponsor it.

>   
>>>  
>>>       
>> We have not made any changes to bug assignment (though I have my own 
>> opinions about that).
>>     
>
> No, but what is being changed is who can do what. And you previously stated
> that people shouldn't assign themselves to bugs they aren't going to fix. I
> think that is very true and perhaps a solution to the current problem is to
> allow the person who is assigned to a bug to change the status as
> neccessary because that is the person doing the actual work.
>   
OK, but that would only work if you also limit who can assign, otherwise 
you can just assign a random bug to yourself and mark it Fix Released 
(as you can do now). Under that model, if you ask to have it assigned to 
you, then you should be able to set any state up to Fix Committed. That 
should work.

>  
>   
>> I agree that we should encourage more people to work on bug fixes. If 
>> this change makes that more difficult then we need to find solutions to 
>> that.
>>     
>
> Well, I think Scott's point is that if the people affected by such a change
> were consulted earlier on then maybe a better solution would have been
> found in the first place. A UDS BOF is no where near enough input on
> essential workflow/permission changes.
>   
I agree that this should have been handled better. I was only made aware 
of tomorrow's change this afternoon and I'm the head of Canonical's 
distro QA team :)  We are a big project and messages do sometimes get 
lost. The fact that major decisions are taken at the UDSes where only a 
very few can attend has always been a problem. Those direct sessions are 
also very productive, so I'm not sure there is an easy answer.

> Perhaps this is all a lot of misunderstanding and a big deal over nothing,
> but sudden changes to one of the most important workflows we have maybe
> need more warning/discussion in the future.
>   
I agree. This should have been more transparent.

Henrik