Proposed changes to workflow bug management

Yuriy Kozlov yuriy-kozlov at
Mon May 26 21:18:41 BST 2008

On Mon, May 26, 2008 at 3:52 PM, Caroline Ford
< at> wrote:
> Forwarded as requested
> ---------- Forwarded message ----------
> From: Scott Kitterman <ubuntu at>
> Date: 2008/5/26
> Subject: Proposed changes to workflow bug management
> To: ubuntu-devel at
> 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
> public.
> 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.

I think this is a bad idea just based on the transparency issue.
Duplicate bugs and the other disadvantages will be a problem as well.
I think "Occasionally someone does something they're not supposed to,
so let's hide these from everybody" is entirely the wrong approach.

Why not just use a tag? or heck, write BUG SQUAD DO NOT TOUCH at the
top of the description.

~ Yuriy

More information about the Ubuntu-bugsquad mailing list