Proposed changes to workflow bug management

[Yuriy Kozlov]

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:
>
> https://wiki.ubuntu.com/UbuntuDevelopment
> https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive
> https://wiki.ubuntu.com/UbuntuDevelopment/Merging
> https://wiki.ubuntu.com/MainInclusionProcess
> https://wiki.ubuntu.com/Bugs/HowToTriage
>
> The last page above has a draft list of types of workflow bugs:
>
> https://wiki.ubuntu.com/Bugs/HowToTriage#head-0670f256d42484d8f9d0cec896eb2c05e43388e3
>
> 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