[Desktop_architects] Cross-site bug tracking
mike at easysw.com
Tue Apr 10 14:08:56 PDT 2007
Bryce Harrington wrote:
> 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
> 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 organizations, there is at least one person between the
reporter and developer, often called the "screener". This
person checks for dupes, required information, etc. and then
assigns the report to the proper group or person.
> 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.
That's where the screener and/or better bug reporting forms that
collect required information comes in handy - they can make sure
the required info is present so that the developer isn't bogged
down in minutia.
> 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
Right, and if you have a form that responds differently depending
on the type of bug (e.g. you select crash bug and the "upload
backtrace" field is enabled and required) then you can ensure
that you have something...
> 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.
The CUPS bug tracker (http://www.cups.org/str.php) uses 5 possible
states (New, Pending, Active, Closed w/o Resolution, Closed
w/Resolution) and 5 possible priorities (1 = RFE and 2 to 5 are bug
reports with 5 being a critical issue) to prioritize things for
the developers. Developers have access to some extra features
that normal users don't see (batch updates, etc.), which helps
to make screening and processing of bugs simpler.
The same bug database is hooked up to a dynamic "road map" page:
I've used the same tracker on a bunch of other projects (FLTK,
HTMLDOC, Mini-XML, Newsd, and soon EPM) with good results.
FWIW, it's all implemented in PHP using a MySQL database; other
databases could be hooked up pretty easily since all of the DB
access is abstracted...
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
More information about the Desktop_architects