Hi,
Stephen Frank schrieb:
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 don't think I understand this right. Are you saying that basically all (or most) of the issues would have a default priority (eg. P3) to begin with, then QA would modify the priority to match the actual need, or are you saying that the issues coming out of the simple interface would already have a higher priority (eg. P2) by default?
From what I understand, Christian is saying the first.
If the first is true, would we want to make sure the issue had seen QA before developers addressed it? (Do developers only look at issues with the oooqa keyword?)
This is, waht the current process is about. Users will file issues as
unconfirmed. QA will take care of those issue, verify them, reassign,
collect data ... and set them to new.
Developers schould only look at issues in status new.
So .. really don't bug the user with something abstract like "prioity".
In most cases, the reoprting user will set the priority to high.
[...]
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.
*-and---
And I have to disagree here. Seeting priority has not much to do with
developer ressources. It is a measurment, how "bad" a bug is. So .. even
if we had no developers at all, a bug that causes an unavoidable crash
on every start of OOo would have top priority.
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?
You say above the QA should not care about priority, and to a certain extent I
think this is true.
This is one big reason I am hesitant to upgrade a priority; I am not a developer. I feel like I must think harder about saying "this issue is definitely high priority" than I must about downgrading an issue that is obviously not a higher priority. Most issues that I have looked at which began life as a P3 but get upgraded to a P2 were upgraded because a developer determined that the underlying code issue was important enough to receive a P2, or because a developer thought the missing/broken functionality was important enough to upgrade the priority. (This might not be a trend, but it has been my experience.) Without a good picture of the code, I feel like it's not that easy to upgrade an issue unless it very clearly meets the P2 requirements. (The issues I have seen upgraded are often in gray areas.)
There are, on the other hand, many cases where a P2 issue set by a user clearly
does not meet the P2 requirements and can be safely downgraded to a P3.
Hmm.. you should know, that those people who raise (or downgrade)
priority are QA engineers in most cases, not developers. In general
thess are QA engineers, who are sitting close to development and have
therefore more knowledge about the code.
But I last time I asked, the work done by QA community members was higly
appreciated (so .. it was nice to have the priority set to correct level
in the first place .. but it's no big thing, if it has to be realigned
in such grey zone cases).
As a QA volunteer, I use two things to determine which issues I QA first. First
is priority (because it helps me narrow down the list of 600+ issues waiting
for QA). Second is what area of the product it is (I try to QA things for the
product components I understand the best). My thought is that I should care
about priority so that I can look at the higher priority issues first so as to
spare developers wasted time with unconfirmable high priority issues.
This is also the way I work. And that's why I don't like to see any
issues that come in with a higher "default" priority than 3. And I would
not like to "force" the user to raise priority. The problem I see is
that users will start to "trick" priority, so that their issues would be
serverd first (this happens already).
And .. there is one point, why it is easier to raise priority than to
decrease it. But this is not a technical. If you raise priority, the
reporter will be happy about it in most cases. If you decrease it, the
reporter will often be upset and start to discuss.
But this is just one thought to avoid unnecesary discussions.
André
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
