Re: Severity levels

[James Mckenzie]

Darragh Bailey wrote on May 5th:
> On Mon, May 04, 2009 at 11:24:58AM -0700, James Mckenzie wrote:
> > Ben Klein wrote on May 4th:
> > > Final post from me.
> > >
> > > 2009/5/5 Nicklas Börjesson :
> > > > b) I thought that priority was developer priority and severity was
> > > > severity for the users.
> > >
> > > Nope. Both for the benefit of developers, hence why they're both on bugzilla.
> >
> > One question:  Does Bugzilla have a place for user's to place the Impact on their ability to use a Windows program?  This is much different than the priority and severity fields.
> >
> > James McKenzie
>
> In catching up on this long discussion, this is the first post that I've
> seen that actually comes close to pin-pointing what is being requested.
>
> Current:
> Severity = messure of bug impact on wine
>
> Requested:
> Severity = message of bug impact on application running in wine
>
> IMHO the bugzilla severity field is not the right place to measure 
> impact to other applications of bugs in the current development. 
> Attempting to track that type of information in the severity field 
> will always lead to confusion and problems.

As a reminder, Bugzilla is for developers to work in user discovered issues.

The Severity field, as it is, is correct for developer/triage evaluation of 
discovered issues.  It should not be changed.

However, a developer should be aware of the impact on the user experience and
the user's determined severity of a problem.  Users should not be determining
this through the use of the severity and priority fields.  I have discussed
the use of an impact field to have the user state what impact the problem has
on their ability to use/install a particular application.  Some problems have
a more severe impact on certain applications.  The use of metabugs to follow
what applications are affected is HIGHLY discouraged.
The users of Wine should be able to state, in one place, what the bug is, what
its impact to them is and the status of repair and/or workaround(s) for the bug
is.  The Applications Database is the location where a user can input what they
found through use of Wine by Linux/UNIX version/distribution and Wine version.

Bug reports should reside in Bugzilla and users should be able to input bug 
reports quickly (<10 minutes for a non-English speaking user.)  This seems 
to not be happening at the present time and users are confused by the Bugzilla
interface and fields presented to them.  We should not rely on the ability
for users to read and understand what field does what but only present to them
fields needed to be filled out by users when they submit a bug report.  Since
the severity and priority fields are developer only, they should not be present.
The proposed impact field should be a drop down list only and present common 
impacts encountered by users, such as "Unable to Install Application", 
"Unable to run application","Screen is unreadable","Text not appearing on 
screen","Graphics are garbled".  This allows the user to provide input 
and allow the triage team to provide feedback to the user as well as
assign appropriate severity and priorities to bug reports.

Please advise if this is what the project desires to do.  Again, this is to
improve the user experience for the unexperienced (nOOb) Wine user.  Experienced
users do not have these difficulties but this takes time away from developers
and triage teams to provide user education.

James McKenzie

Severity levels

[Rosanne DiMesio]

On Tue, 5 May 2009 13:28:45 -0400 (EDT)
James Mckenzie  wrote:
> The proposed impact field should be a drop down list only and present common 
> impacts encountered by users, such as "Unable to Install Application", 
> "Unable to run application","Screen is unreadable","Text not appearing on 
> screen","Graphics are garbled".

If I can't install or run an app because text is not appearing on the screen and the graphics are garbled--in other words, the screen is unreadable--which item am I supposed to select? Or at the other extreme--what if my problem doesn't seem to match anything on the predefined list?
> This allows the user to provide input 
> and allow the triage team to provide feedback to the user as well as
> assign appropriate severity and priorities to bug reports.

There's already a field that does exactly that: the description. It allows users to describe the problem in as much detail as they wish, including its impact, and unlike a drop-down list, is not limited to common issues. I don't see what an additional field to repeat this information in vague terms will do to help anyone.

Severity levels

[Nicklas Börjesson]

> However, a developer should be aware of the impact on the user experience and
> the user's determined severity of a problem.

That has been my point all the time. I was told that the users perceptions 
were not important since, a least according what I understood, 
they could not be trusted to be objective in their classification.
Also, it was not very important to know their priorities anyway.
> Users should not be determining this through the use of the severity and 
> priority fields.  I have discussed the use of an impact field to have the 
> user state what impact the problem has on their ability to use/install a 
> particular application.

However, I thought adding a extra field would be too bold a proposition, so I
proposed to change the severity field instead(which I felt was unlinear anyway).

Regarding the interface of the bug reporting I am also with you. 
It is simply not simple enough for normal users. Too many "knobs".

The "problem" is that it is felt that enough bugs are reported anyway, and 
that therefore, no improvements are needed. 
Maybe that's correct, but I just can't help to think it is a bit of a strange mindset.

//Nicklas