Hi Christian, Just a couple more thoughts...
> 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? 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?) If the second, I agree with someone's - can't remember whose - comments that we wouldn't want to fill up issuezilla with higher than priority issues by default. >> [...] >> 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--- >> 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. 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 how I have been working anyway. I am open to suggestions. Steve
