Severity levels

[Ben Klein]

2009/5/3 Nicklas Börjesson <Nicklas.Borjesson at ws.se>:
> It just feels like the entire project should become a bit more user-centric.
> Now I am not just talking about shinier graphics but about attitude.

Bugzilla not user tool. Bugzilla developers' tool. Bugzilla need work
like developers want.

2009/5/4 Nicklas Börjesson <Nicklas.Borjesson at ws.se>:
>>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.
>
> No, I mean that the actual meaning of the words "low", "medium", "high" and "Critical" will suffice.



No they won't. In order for the severity levels to be meaningful, they
need to be strictly defined. Take the example of contracts or
legislation, where otherwise unambiguous words are defined in context
just to make it 100% perfectly clear what's being talked about. Wine
is a *big* project, and we really don't need massive confusion over
what the severity levels mean.

> I think most people have a fair understanding what "medium" and "critical" means.

Apparently not. Most people don't see the bigger picture, they only
see what they're doing right now (e.g. Critical bugs filed because
they have an assignment due the next day when it is in fact only a
Minor or Normal bug).

> This is not meaningless at all, to trying to clarify these levels is quite pointless though.

OK, so give examples of what would be "low", "medium", "high" and
"critical" bugs.

> Yes, some people tend to exaggerate their issues, but that's just the way it is.

And removing the definitions can in no way help this.

> And to my experience, they are few. Most actually don't exaggerate as much.

So you're suggesting to completely overhaul the system for only a FEW
users to be more productive in submitting bugs?

> To them, the situation IS critical, bordering on panic.
> Rather, thinking that their users are exaggerating is a way for developers to not let reality come to close.
> Hell, I do it myself right now. :-)

Yes, but that's not what the "severity" indicates. As it has already
been said, focusing on a particular user's problem just because THEY
think it's critical is completely unproductive for a large (massive?)
project like Wine. Wine devs need to look at the big picture, as in
"What is the overall impact of this bug? Who and what is affected?
Roughly how many applications does it affect/break?" and THAT's what
the "severity" setting is for.

Another way to look at severity is a rough indication of how much code
change is expected to be required to fix the bug. In theory (but by no
means in all cases in practice), a Minor bug should have very little
code changed compared to a Major bug. Again, severity is there for the
*developers* to use and understand, not for the users.

> I don't see how the reproducibility connects to the severity level?

It doesn't. It connects to the interaction between user and developer.
You're talking about user impressions - "THIS NEEDS TO BE FIXED NOW OR
I WILL DIE" - I'm talking about REAL bug report information - "When
you click on this button then hit this menu option, the application
draws squiggly lines all over the screen. Graphics card has nVidia
180.29 drivers."

> Regarding the priority flag..i was referring to it's visibility, not its state.

Bugzilla doesn't (and can't) know the difference between an average
non-tech-savvy user and a hard-core developer. If the priority flag is
hidden from average users because they shouldn't change it, then it
will also be hidden from people who know how to use it properly, and
more importantly the people who NEED to change it (to make their
report complete).

>>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).
>
> My point is that there should be no need for that flag.
> Let the users have it as input, and let the developers use component+priority.

Component + priority gives absolutely no indication on the overall
impact of a bug, as I have mentioned before. Priority and severity
(developer-side severity) do not have a 1-to-1 relationship.

>>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.
>
> You are right. I don't like it.

Called it!

> Especially because the bug tracker is the entire projects tool, not only the developers.

Who runs the project? Developers. Who fixes bugs with committed code?
Developers. Who uses bugzilla the most? Developers (most bugs come
from users, but developers are the ones who respond to them). What
type of project is the Wine project? Software *development*. We're not
in customer service, and even if we were, the bug tracker would be
pretty much the same.

> I this matter can only compare with my own professional(commercial) experience and there,
> the ones submitting bugs has a *lot* to say, since they won't submit bugs unless they are
> critical if we don't present them with a smooth interface.

I don't see this happening now. Do you?