Proposed changes to workflow bug management

Scott Kitterman ubuntu at
Mon May 26 20:45:36 BST 2008

At UDS Intrepid we had a good discussion between a few Ubuntu developers and 
some people who are active in bugsquad (I recognize that many developers also 
triage bugs.  The discussion was focused on people who triage, but are not 
developers.).  I accepted the action to present the issue and proposed 
solution to the development community for comment (I know bugsquad needs to 
discuss this too, but I'm probably not the best one to lead that discussion).  

This is my best attempt to capture the proposal that resulted from our 
discussions at UDS.  I'm sure I've missed things/made mistakes.  Please point 
them out so it can be fixed.  This writeup is no doubt slanted based on my 
perception of the problem.  No offense/insult against bugsquad is intended 
here.  If it's present, please let me know so I can fix it.

Problem: A number of development processes use bugs to track work flow.  This 
class of bugs has unique rules and bug status has different meanings (even 
perhaps different meanings depending on the phase of the development cycle).  
This class of bugs rarely benefits from work by bugsquad (non-developer) 
triage efforts.  In some cases changes may actually be harmful.

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.

Rationale: The most reliable way to ensure new triagers do not involve 
themselves with workflow bugs is to make it so they cannot see them.  Through 
appropriate team permissions in Launchpad, workflow bugs can be visible to 
those that need them.

Advantages:  No bugsquad process changes required (the current "Special types 
of bugs" section would be changed to indicate ubuntu-bugcontrol should be 
asked to see if the bug needs to be added to the workflow bug class if a 
triager believes they have found one not appropriately marked).  The risk of 
inadvertent/incorrect changes by people not involved in the development 
process would be greatly reduced.  Noise level changes appearing in the 
bugmail stream would also be reduced.

Overall harmony between bugsquad and developers should be improved.

Disadvantages: Some development work is needed to mechanize the proposed 
process changes.  Ubuntu development becomes slightly less transparent.  
There is some risk of duplicate bugs being filed.  Process change always 
causes some disruption.

Documentation impacts: The following wiki pages will need to be updated:

The last page above has a draft list of types of workflow bugs:

Since needs-packaging bugs are generally filed by end-users they would be kept 

Development requirements/issues:

1.  Some launchpad changes are likely needed to effect this change.
2.  Requestsync will need to be modified.
3.  Additional scripts may be useful to aid in workflow bug filing
4.  Need to identify teams that would have access to workflow bugs:

Bug filers always have access to a private bug, so those who are not in an 
appropriate team would still have access to workflow bugs they file.

ubuntu-bugcontrol would have access to these bugs (ubuntu-dev is a member of 
this team, so it gives all developers access).  universe-contributors should 
also be a member.  One open question is, should there be an open team that 
has access to these bugs?

Please discuss.

Scott K

P.S.  Would someone who is subscribed please forward this to ubuntu-bugsquad.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : 

More information about the ubuntu-devel mailing list