Hi Stephen,
On Thu, Apr 13, 2006 at 10:25:48AM -0400, Stephen Frank wrote:
> Thanks for your thoughts. I have some further comments...
>
> > 1 is not for crashes...
>
> 1 is for crashes, but not all crashes.
Exactly. And when the initial comment was "reserve P1 for crashes", then
this is wrong.
> [...]
> >> How high a priority do you feel fixing this bug should be?
> > [...]
> >Most of this already is included in the first question.
> >e.g. crahs vs unwanted behaviour vs typo...
>
> Some of this information is answered, but certainly not all. For example, a
> "crash" report could be automatically set to a P2, but a crash is only one
> of 7 reasons for an issue to have a priority of 2. The others include:
> unacceptable slowness in a normal operation or extremely poor
> responsiveness, an essential feature is not working, and data corruption
> without an "undo" option. None of these is technically a crash, but we still
> need some way to find out if the user has experienced them.
Since these issues need through QA first, I'd prefer QA to set a
higher-than-default priority.
You far less need to increase prio than to decrease it.
> > I'd not offer the priority in the bug-assistant directly.
>
> That is a good point. Maybe instead we can ask a questions along the lines
> of "Are you reporting a bug that has caused you to experience any of the
> following: (1) data corruption or loss, (2) loss of ability to use an
> essential feature, (3) extreme slowness in program operation, etc?" Again,
> the wording is not the important bit. The important bit is that we can still
> identify high priority issues that aren't crashes. Currently, there isn't a
> way to do this.
I'd try to remove as many fields as possible, ask only those questions
that are really necessary. I'd rather not have these questions (for the
reason above: changing the prio from P3 to a higher one is not necessary
most of the time.
> [...]
> For me as a QA volunteer, priority is the first thing I look at when trying
> to verify an issue.
In my opintion, QA should not care about priority. Devels should. But
not QA.
> I go for P2 issues first (usually to check to see if I
> need to downgrade them), then I move on to P3 issues. As I said before, it
> is easier (for me at least) to downgrade an issue to P3 than upgrade a P3
> issue to P2.
Why is that? Why is it easier to downgrade than to upgrade?
> So, in my mind it would be better to have a way - direct or
> indirect - for the user to set the priority at P2 to start with so that the
> issue can be adequately QA'd in a timely manner.
As above. The usual case for P2 is a crash, so the "classification"
takes care of this. Maybe we could add "major bug", but add an
explanation that it really needs to be /major/, maybe with some
examples.
But this is enough. No need for another selection mechanism.
ciao
Christian
--
NP: Dimmu Borgir - Når Sjelen Hentes Til Helvete
Join #qa.OpenOffice.org on irc.freenode.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
