Re: bug rating

[Carl Sorensen]

On 12/10/09 3:29 AM, "Graham Percival" <address@hidden> wrote:

> On Thu, Dec 10, 2009 at 02:15:21AM -0800, Mark Polesky wrote:
>> Graham Percival wrote:
>> 

> But if nobody is working on fixing them, who cares what the label
> is?!?!
> 
> The low vs. medium priority has historically been a mixture of
> "bug severity" and "order that somebody might try to fix it in".
> If somebody wants to go through all 350 bugs that are low and
> medium, and prioritize them according to "how ugly do they look",
> I don't care.
> 
> Talking about this is SERIOUSLY in "rearranging the deck chairs
> while the titanic sinks" territory (in case you didn't catch the
> earlier reference).  I don't know of any bug fixers who are
> sitting around twiddling their thumbs.  Instead, they're trying to
> learn enough about the internals to fix the issue they're already
> working on.

As long as we're talking rearranging the deck chairs, in the hopes that a
better arrangement will provide better guidance to those who can hardly wait
to get started fixing a problem, I'd like to suggest that the importance of
a bug is related to at least three factors (drawing inspiration from the RPN
of FMEA : http://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis):

1. Severity of the Bug.  In descending order of severity, I can think of the
following:  Stops execution (i.e. Segfault) -- 10; Musically wrong output --
8; Obviously ugly output -- 4 to 7; Minor nitpick errors -- 1 to 3.

2. Probability of occurrence of the bug.  In descending order: Occurs in
virtually all scores -- 10; Commonly occurs in scores -- 7; Occurs only
rarely in very specific conditions -- 1 to 3, depending on the number of
conditions that need to be met.

3.  Difficulty of working around.  In descending order: No known workaroundp
-- 10; Workaround requires customization for every particular case (e.g.
changing shape of slurs) -- 8; Workaround requires standard code at each
occurrence (no customization required) -- 4-6, depending on code; Workaround
requires code to be added once in the file -- 1-3.

The overall Bug Priority Number would then show up as the product of the
Severity, Probability, and Difficulty values.

Of course, I'm not proposing that anybody stop fixing bugs in order to
perform this calculation.  I just wanted to get the thought in this thread
in case we ever want to seriously approach this in the future

Actually, I think that much of the disagreement about bug priorities comes
because different people are thinking about different aspects of the bug.
The one common point we have now is that segfaults get high priority.

Thanks,

Carl