Proposed changes to workflow bug management

[Scott Kitterman]

On Thu, 29 May 2008 05:52:09 +0900 "Emmet Hikory" <persia at ubuntu.com> wrote:
>Scott Kitterman wrote:
>> Agreed.  I think "Don't mark on bugs you don't understand" is a much more
>> useful approach than setting rules on which classes of people can touch
>> which kinds of bugs.
>
>    Just to be fair, and in reference to some of the discussions that
>were partly responsible for initiating these threads, this ought have
>a corresponding "educate rather than complain" for those cases where
>bugs are handled in a non-ideal manner.  While we've been discussing
>primarily workflow bugs, the same can also be seen in other cases
>where people less familiar with our various launchpad processes (for
>any team) may make an incorrect adjustment.
>
>    In addition, I think it is important to define "understand" to be
>about the type of bug, and how it relates to the package.  I don't
>believe it is necessary to understand the specific issue that causes
>the bug in order to start working on it (especially so for those who
>are not also developers), although I can see value with this rule
>where it is more general: compiled code often benefits from a
>stacktrace, interpreted code often benefits from a backtrace, display
>or sound issues often benefit from certain files, etc.  All of these
>may be crashes, but the information required to accurately determine
>the problem differs.  Similar guidelines apply to any class of bugs
>(workflow, crashes, typos, unexpected behaviour, feature requests,
>etc.).  Similarly, different groups of packages are handled
>differently, so for example GNOME bugs are usually pushed upstream,
>Games bugs are usually pushed to the Debian Games team,
>Install/Upgrade bugs are often fixed directly in Ubuntu, and these
>differences are also in the repetoire of things worth learning, and
>things worth educating others about.
>
This is all very sensible.  I'd go a bit further and suggest we need 
something conceptually similar to the most famous phrase of the Hippocratic 
oath, "First, do no harm".

Harm can come in many forms.  Not recognizing a workflow bug and setting 
such a bug to an inappropriate state is only one case.  I've also seen 
cases where people didn't take care to frame a response to a bug in a 
thoughtful way and a negative experience for the person reporting the bug 
resulted.

Personally, I find quality more important than quantity in triaging.  A bug 
is often a user's first interaction with the Ubuntu development community 
(lest there be any doubt, I consider triagers part of that community.  I 
think that developing that relationship, teaching the reporter how to make 
better bugs, and encouraging them to become involved in the process are at 
least as important as figuring out what went wrong and getting it fixed.

Scott K