How to determine bug severity level?

[Michael Binder]

Hi everyone,
I am getting ready to report a bug.  Its my second bug, but will be my 
first report (J Landman Gay kindly reported my first bug after it was 
discussed on this list).

I am a bit uncertain about how to rate the severity level.  Actually, I 
think I do understand how to rate the level, but I disagree.

My first bug was rated a minor severity level which IMO is wrong.  That 
bug, when unrecognized, caused my standalone apps to lose user data 
(unbeknownst to the user).

This new bug (see yesterday's thread: 'List fields MultipleHilites 
property') causes my application to return bad data.

Thinking about this, I WOULD RATHER HAVE MY APPs CRASH then report 
wrong data or lose data.  (if the app crashes, at least the user KNOWS 
that they lost data).

I know that there are work-arounds for these bugs.  But many of you 
have these bugs in your stacks, and if you haven't been been affected, 
you're just lucky that your user didn't elicit the bug.

For example: IF you have a list field set to allow multiple contiguous 
selected lines, AND you have not incorporated Ken Ray's workaround, 
THEN you have at least a cosmetic bug.  If you then use the 
'selectedlines' function to doSomething with the hilited lines, then 
you have a serious bug. (because the lines returned by the function are 
not the same as the hilited lines that the user sees).  In my app, that 
resulted in my user editing data that she did not intend to edit, and 
not even realizing the mistake.  Honestly, I would rather my app crash 
then do that.

So, how would you rate this bug?

By the way, IMO the solution for the rev team is a two step solution:
First, they should quickly document these anomalies and their 
work-arounds.  Once they are documented, they are not bugs...  They are 
converted to enhancement requests.  Then, at their leisure, the team 
can actually fix these things.

I'll be off list for a day, but I look forward to seeing your responses 
tomorrow.

--Michael Binder