Proposed changes to workflow bug management
yuriy-kozlov at kubuntu.org
Mon May 26 20:18:41 UTC 2008
On Mon, May 26, 2008 at 3:52 PM, Caroline Ford
<caroline.ford.work at googlemail.com> wrote:
> Forwarded as requested
> ---------- Forwarded message ----------
> From: Scott Kitterman <ubuntu at kitterman.com>
> Date: 2008/5/26
> Subject: Proposed changes to workflow bug management
> To: ubuntu-devel at lists.ubuntu.com
> 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.
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.
More information about the Ubuntu-devel-discuss