launchpad-dev team mailing list archive

[Jeroen Vermeulen <jtv@xxxxxxxxxxxxx>]

On 2011-08-26 10:25, Robert Collins wrote:

> Users seek help: need something like 'answers'.
> Some of these requests for assistance uncover symptoms of a problem in
> the software (e.g. a crash, or user confusion from the UI). Call this
> a problem statement.

> A single *bug* could link or incorporate *many* problem statements.
> Anyhow, as I titled this, this is just me ruminating, but I'd sure
> like us to find a core model that will address the friction we're
> seeing today rather than tacking on more and more bits on the side :)

You may be interested in Kirit Sælensminde's work on bug classification, 
which I summarize (not too well, probably) here:

http://pqxx.org/development/libpqxx/wiki/AllSoftwareIsBroken

It's probably too radical to switch to, but I did find it insightful. 
Personally I liked it so much, even if Kirit admits it needs more work, 
that I implemented it in my own bug trackers and converted all 
outstanding bugs.  It's not a complete classification, but I noticed 
some very real advantages:

 * Report the problem, not the task.

This is a classification from the user's perspective.  It minimizes 
implications for or assumptions about how the problem should be fixed.

 * No importance tug-o-war.

It sidesteps the notion of objective importance of a bug.  You don't 
invite the user to say "Critical" nor the developer to downgrade that to 
"Wishlist" (with the predicable hard feelings).  You keep a clear 
separation between how the problem affects the user and how it fits into 
developers' priorities.

 * No euphemisms.

There's a good match to how users will tend to feel about the problem. 
You don't force them to classify a bug as, say,

(a) small flaw in the diamond that is our software;
(b) limitation of your personal ability to deal with computers;
(c) something that people of your intelligence level need explained to 
them in additional documentation.

 * The top priority is built in.

One classification is "fails to communicate failure."  This isn't the 
same as the failure itself; it's something that probably needs urgent 
fixing in itself even if the failure per se is not a priority.


Jeroen