While we're on the topic of improving bug trackers, I'd like to throw
out one other thought I've been kicking around while tinkering in
launchpad/bugzilla/sf/etc. 

Managing bugs in a bug tracker is a LOT of work, and often the work
boils down to two roles:  The reporter, and the developer.

In many bug trackers, the unwashed masses are invited to report bugs.
In general this is a good thing, but time after time we see that most
users don't know how to report bugs properly.  The result is increased
time expenditure by the developer, to request additional information,
gain clarification, do research into the user's hardware or OS
peculiarities, etc.

There are various ways to address this, including limiting who can
report bugs, instituting point systems to sort out good reporters from
bad, recruiting dedicated triagers, creating documented bug reporting
processes and flaming those not following it, and so on.

However, what would be *really* handy is to have mechanistic ways of
triaging bugs.

For example, if the bug is a crash bug, it could require a backtrace.
If it's a rendering problem, it could require a screenshot and copy of
the original file.  If it's a usability problem, it would require either
a detailed set of steps to reproduce or a screen capture movie.  And so
on.

Or a criteria could require that the bug has been seen by several
others, or that has a volunteer for testing fixes, or that the reporter
is "trusted" (perhaps through # points earned).

Essentially, this lets bugs and bug reporters be divided into two
categories.  Let's call them "Flags" and "Reports".

The difference is that anyone and anything can Flag a bug, but
developers will only follow up on Reported bugs.

Flagged bugs could come from random users, built-in crash report tools,
automated tests, or myriad any sources.  Flagging a bug is trivially
easy.  But if the user wishes to see the bug investigated and ultimately
fixed, this is just a starting point.  They interact with the bug
tracker to find appropriate tags, upload files appropriate for the type
of bug, check for dupes, and so on.  Once the system sees all the
required work has been done, it promotes it from Flag to Report and
developers are notified and brought into the picture.

Many bug trackers have a roughly similar workflow to this.  For example,
many distinguish between untriaged and triaged bugs.  Some distinguish
between "support requests" and "bug reports".  But generally these
involve manual management (and thus developer time) to move items from
one pool to the other.

Bryce
_______________________________________________
Desktop_architects mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/desktop_architects

Reply via email to