Oh, and wrt prioritization, even though SF permits 10 levels of priority per bug, there doesn't seem to be much need for more than four levels: high(9), med(6), low(3), and unprioritized(5).

We use the prioritization for 'criticality' rather than implementation order (which is unpredictable).

Crash bugs are generally always high(9), as are bugs related to file open/save problems, file corruption, loss of backup, or other things that could cause data loss for users or prevent them from being able to use the application.

Bugs which affect usability, functionality, behavior, etc. are generally medium(6), although important ones are bumped up to high and unimportant ones are dropped to low.

Quirks, really obscure things, and minor nit picky things would be low(3).

The prioritization level isn't used to indicate when the bug will be fixed. Bugs seem to get fixed whenever their time has come. That said, we do try to make an extra effort to address all the critical bugs prior to a release.

Bryce

On Tue, 13 Apr 2004, Kees Cook wrote:

say, is there any kind of "method" we should follow when going over people's bug reports, patches, etc? I didn't find anything in the Wiki about it.