Severity levels

Ben Klein shacklein at gmail.com
Sun May 3 09:15:56 CDT 2009


2009/5/3 Nicklas Börjesson <Nicklas.Borjesson at ws.se>:
>
>>I disagree. When first introduced to them, I found the severity levels
>>to be suitably vague to make me read the definitions. Once I read
>>them, it was clear to me what each level means.
>
> Suitably? Do you mean that the severity levels are the way they are to make people read their definitions?  :-)
>
> Jokes aside, that's exactly what I don't want.
> I want them to be even more vague(Low, Medium, High and Critical) and without any definitions except for the highest level.
> This way, one will elicit more how the user perceives the overall impact of the bug, without having to shoehorn them into some level that only partly matches their impression. Done with the help of the users indisputable "common sense", of course.

So you suggest making the severity ratings meaningless to anyone but
... well, you don't actually mention anyone knowing what they *really*
mean, but I assume an exclusive clique of developers or bugzilla
admins? Users have different opinions on what level of bug they
encounter depending on what *task* they're trying to perform, which is
not particularly useful to developers who need strict reproducability.

> Also, the priority flag should not be visible to the user by default, it should be a strangely named setting somewhere in the user preferences.

It already is a strangely named setting, but the user preferences is
far from the right place for it. It still has to be on a per-bug
level, and although it may not be the most useful option on bugs it is
still used by developers in-the-know, so maybe an additional message
that says "Don't change the priority setting unless you know exactly
what you're doing"? It's academic anyway, as the priority can be
appropriately adjusted later.

>>But bear in mind the severity levels are there
>>to help the developers categorise the bugs, and they are not there to
>>provide feedback to the average non-coding user.
> For categorisation, there could be a separate category flag if the "component" categorisation + priority wouldn't suffice.

There already is a separate category flag. It's called "severity" and
it indicates roughly the amount of *functionality* lost due to the
bug. "Priority" does not indicate the severity of a bug; a bug may
have low priority due to limitations outside of Wine (such as some
blocker bugs for copy-protection systems which can't be supported in
Wine).

> Whatever. There are many ways to do it. But currently, the users' impression of the problem get lost and/or skewed.

You're not going to like this, but users don't matter quite *that*
much on bugzilla. The bug tracker is a developer's tool, and although
users are essential to the process (submitting bugs and new
information on request), it should be designed as a developer's tool.
A user's impression of their problem is irrelevant to the hard data
they can provide about lost or missing functionality.



More information about the wine-devel mailing list