Hi again, Thanks for your thoughts. I have some further comments...
> 1 is not for crashes... 1 is for crashes, but not all crashes. The guidelines state that P1 is very rarely used, but can be applied for "Reproducible, unavoidable crash or freeze in functionality indispensible for the whole product; e.g. crash upon loading arbitrary documents" You are correct, 2 is usually more appropriate: "Crashs or freezes during normal operations of the application." More on this further down... >> How high a priority do you feel fixing this bug should be? > > I'd not mention the fixing in this case. Everyone thinks "my issues are > so important"... This is true; most people do think that their issues are important. As a QA volunteer, I much more often end up downgrading priority than upgrading it. (I think I've only upped the priority of an issue once.) Still, it isn't very difficult to go through and downgrade P2 issues that have been mislabelled, but it is harder to identify P3 issues that really should be P2's. (This is mostly because there are so many more P3 issues.) >> -Top priority (translates to a priority of 2) >> -Regular priority (translates to a priority of 3) >> -Lower priority (translates to a priority of 4) > >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. > 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. > People either do not read or understand these guidelines. > the "we might want to reserve 1 for crashes" demonstrates this. The fact that people don't read or understand the guidelines just makes a better argument for putting them in a more accessable place. Although I think some people, esp. QA volunteers, do read these guidelines pretty regularly. The point I was trying to make is that we would not want the user who is reporting a bug to be able to set a P1 on any issue they choose. Hence we would limit the ability of simple bug-report interface to set P1 to only issues where a crash had been reported. (Even then, you would have to meet the other criteria for a P1 issue, ie, a "reproducible, unavoidable crash or freeze in functionality indispensible for the whole product.") Issues not reported as a crash might still be P2's, but they almost certainly won't be P1's. For me as a QA volunteer, priority is the first thing I look at when trying to verify an issue. 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. 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. Regards, Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
