[mb-users] Fwd: Bug Triage

[Lauri Watts]

I have an idea to run by everyone.

In other projects I actually do work on (as opposed to this one, where
I mostly just spout off :), all bug tracker comments go to a mailing
list that is open subscription to everyone who has access rights to
the bug tracker.  These people perform triage on the bug reports,
before they get to the developers.

What do I mean by triage?  The major functions:

1: Weeding out the nuisance and duplicate reports, so developers
aren't wasting their time and getting frustrated by having to repeat
the same things over and over.

2: Figure out what bug reporters really _want_.  This sounds obvious
but it's really not.  Anyone who's ever searched a bug tracker for
more than 5 minutes, or hey, read one of the recent threads on here,
figures out that what users say is the problem, very often is not, but
users are simply not expressing themselves in terms that make sense
from a 'looking at the code' point of view.  And developers often make
replies that don't necessarily make sense from a 'looking in from the
outside' point of view.   Often things like exposing implementation
details in the UI uneccesarily make perfect sense to a developer, but
little or none to a user, but getting both sides to actually
articulate what is wrong, or that there is something wrong, is like
trying to mediate between two alien languages.

3: Figure out how to fix it.  That doesn't necessarily mean actually
fixing the bug, or even providing a patch, but rather coming up with a
solution that is possible to implement and satisfies the user, even if
the triager doesn't necessarily know the precise details of how it
will be done.  This is really an extension of 2.

How does it actually work?

Bugs that come into the bug tracker, are unassigned, or assigned to
the mailing list user. People who are familiar with the UI but know
how to speak programmer, go through them answer the comments, and work
with the reporter to ferret out the details of the problem, if it's
not clear.  In KDE, for instance, this means people also test patches,
dig through the code to figure out where errors are happening or where
the applicable bit of code actually lives, and very often, restate bug
reports and developer responses in clearer or less combative terms.

Why do I think this will work?

Because I've seen it in action, in much larger projects than
MusicBrainz.  As a bonus it's a way for interested not-yet-developers
to get deeply involved, and a level of familiarity with the code base.
 (indeed, most baby bug triagers end up becoming more involved in
development over time, and most developers make quite capable bug
triagers when dealing with bugs that would not normally be in their
area, oddly enough).  I truly do think that a lot of the problems we
are seeing here is simply cultural: Programmers, especially those from
open source projects, do not tend to make effective communicators with
the users of their products.  That doesn't make them bad people, it's
just two groups who are not always speaking the same language.

What would it take to implement?
Have the bug tracker assign newly created bugs to nobody, if it doesn't already.
Have all bug comments fed into (some easy to parse format, rss,
mailing list, something)
Give a handful of people who feel they have decent investigative
skills, and are able to be diplomatic, enough access to the bug
tracker to allow them to manage bugs.
Provide a place (forum, list, irc channel, whatever) to allow these
people to coordinate a little, so they aren't stepping on each others
toes.

Regards,
--
Lauri Watts