So it sounds like there are really 4 values?<br>normal<br>high<br>fix if possible before release<br>showstopper<br><br>As I've said before, I think it is better to use words, not numbers, and especially not operationally meaningless distinctions like 4 vs. 5
<br><br><br><div><span class="gmail_quote">On 11/26/06, <b class="gmail_sendername">Neal Norwitz</b> <<a href="mailto:nnorwitz@gmail.com">nnorwitz@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 11/26/06, Paul Dubois <<a href="mailto:pfdubois@gmail.com">pfdubois@gmail.com</a>> wrote:<br>><br>> and suggestions were made about how to deal with blockers. So to sum up<br>> what Martin and others have said, they do not use priorities except for this
<br>> pre-release period.<br><br>This is mostly true, but let me clarify. Priorities are typically<br>only *reviewed* just before release. Typically I'll assign any bug<br>that crashes the interpreter a 7-9. I do this when I first see the
<br>bug report. These high priority bugs usually don't stay open very<br>long. We also set some regressions to a higher priority.<br><br>During release, we used priority 8 to signal the bug should be fixed<br>if possible before release. Priority 9 was used for bugs that were
<br>showstoppers. They had to be fixed before release. 7's were<br>sometimes also used, but that was only for information and didn't<br>affect release.<br><br>> Here is another idea for this then: don't have a priority but do have a
<br>> check box or yes/no (probably visible, or at least writeable, by Developers)<br>> that says something like 'Needed for next release if at all possible'. Then<br>> a simple search will find all such issues that are still open, etc.
<br><br>Since it's not a boolean this won't really work. See above.<br><br>n<br></blockquote></div><br>