Proposed changes to workflow bug management

Sam Tygier samtygier at yahoo.co.uk
Mon May 26 23:42:46 BST 2008


Scott Kitterman wrote:
> After some review, it appears that there is no easy way for bugsquad members 
> to reliably identify such bugs that is consistent with their normal work 
> flow.  The most reliable method to identify them by team subscription (e.g. 
> ubuntu-archive, ubuntu-mir, ubuntun-universe-sponsors, etc.), but this is not 
> something generally used in the triage process.
> 
> Proposal: Develop a new class of private bug for workflow bugs and make such 
> bugs private.  Develop a work flow to resolve uncertainties about workflow 
> bugs through ubuntu-bugcontrol.

Firstly I think that making bugs hidden in anyway affects the transparency of development. Currently a compromise is made for security bugs, but hiding bugs for convenience seems wrong.

Secondly, suppose the implementation is an open group. bugs are only viewable to members of the group. Suppose i am a bug triager, but occasionally i need to follow a work flow bug (maybe i made a sync request). now i am a member of this new group so i can see workflow bugs. now the only way i can recognise a workflow bugs is by checking the subscriber list. if i couldn't/didn't do that before, i still wont now.

I think a banner across the top of the bug would be better. maybe the only members of a certain group could be allowed to change the status of these bugs.

Or, if workflow bugs are so different to normal bugs, why track them in the same bug tracker? maybe the longterm solution is to add a workflow tracker to launchpad.

sam




More information about the ubuntu-devel mailing list