How to determine bug severity level?

[Richard Gaskin]

Michael Binder wrote:
> 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). 

I think I must have misunderstood something early on.  When I ran the 
recipe you'd posted I found that the hilitedLines always returned the 
expected value, and only the old legacy HC option (the selectedLines) 
fails to account for the discontiguous selection.

This was the recipe given:

> To demonstrate:
> 1) Create a new main stack.
> 2) Drag onto it a default scrolling list field from the tool pallete.
> 3) Add 5 more lines of text (choices 4-8).
> 4) Make the field tall enough so that you can see all 8 lines.
> 5) Set the multipleHilites of the field to true.
> 6) choose browse tool
> 7) select the first 3 lines of the list field
> 8) Click somewhere on the card so the field loses focus
> 9) Hold the shift key down and click on line 6

When I do that I find the hilitedLines consistenly gives me the answer 
I'd expect.

What did I miss?


> So, how would you rate this bug?

I'm with the rest of the gang:  if a bug loses data or reports bad data 
(not sure which is worse) it gets "Critical"; if it's holding up an app 
from shipping it gets "Blocker".

If anyone on the team disagrees they'll tell you when they change the 
severity, but at that point at least you know you have their attention.

I think it's wise to exercise prudence when using those two severity 
ratings, but when warranted it would be a disservice to both RunRev and 
their customers not to.

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com