Proposed changes to workflow bug management

[Jordan Mantha]

On Mon, May 26, 2008 at 12:45 PM, Scott Kitterman <ubuntu at kitterman.com>
wrote:
<snip>

> 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.
>

While this is true, workflow bugs are pretty much the easiest to work with
because they have well-defined subscriptions, statuses, etc. do to being
used in our processes.


>
> 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.
>

I'm very curious as to why that is. It seems much easier to me to check bug
subscribers (for archive, sru, or release bugs) or titles
(merges/syncs/removals) than making sure a bug is reported against the right
package and has all the information needed for developers to start working
(typical triaging task, no?).


>
> 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.
>

While it's true that the best way to avoid problems is for triagers to not
see workflow bugs in the first place, I can't see this particular proposal
as an acceptable solution. We're effectively trading some complexity on the
triaging end with obfuscation of important developer workflows. It is
important, IMO, that casual contributors or relevent non-Ubuntu developers
(Debian and upstream) can participate in our processes. So we go from one
relativily uncommon but somewhat troublesome problem to one that affects
everybody and may prevent some people from contributing. It seems to me
we're heading in the wrong direction.


> 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.
>

Do we particularily know that this is the case? I'm not necessarily
rejecting it, but I've not seen an analysis that shows how often we have
incorrect changes and what teams "offenders" belong to. Do we know that it's
consistently triagers who are not in ubuntu-bugcontrol?


>
> 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.
>

I'm also concerned about upstreams who may contribute to things like
merge/sync bugs but won't be able to since they won't see them. Would all
package subscribers be allowed to see the bug at least? I believe a normal
private bug works that way but I'm not sure with package subscribers.


>
> 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.
>

I don't think this goes far enough. I feel it's quite useful, in not
critical, for people to see other bugs of the same class/workflow. You need
to be able to check for dups and see what other people are doing.


>
> 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?


The ubuntu-bugcontrol team has something like 200 members, a number of which
are triagers as far as I can tell. It's not nearly as big as ubuntu-bugsquad
(1100 members!) but I see it as primarily as an advanced triaging team. Is
the idea here to keep the workflow bugs from inexperienced triagers but
allow the more experienced ones to "figure it out". It would seem to me to
be rather confusing and counter-productive to have different people in the
triaging team seeing different bugs in search results, etc.

Overall, this feels like an attempt to solve a problem with the
presupposition that the triaging team can't change anything. It also feels
like a classic case of solving social problems with technical solutions. The
cases I've seen primarily boiled down to triagers taking advice badly and
developers being unforgiving towards people who don't know better. Is it
really so inconceivable to to have clear and concise documentation that
helps new people figure out what workflow bugs look like? Is it really so
unreasonable to expect people to be forgiving toward new people who make
mistakes and people to actually learn from mistakes.

Thanks to the UDS attendees who participated in this BOF and especially to
Scott for writting this all up.

-Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20080526/7c7ee2ab/attachment-0001.htm