[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Who decides which bugs are critical?



Some of these don't really look critical to me.  I think of critical
as something that either causes a loss of data, makes the system
insecure, or is a glaring error of lesser proportion.

When I have done this in commercial environments, we made a matrix
like this:

		    Severe		Important		Cosmetic
		(crash, hang, 		(missing or
		 security breech)	 improper feature)
		     
Always			1			1		   2

Frequently		1			2		   2

Seldom			3			3		   3

Rare			4			4		   4	

This is merely an example.  The rankings don't always make sense in
every situation.  The idea is to categorize bugs so that we fix all
priority 1 bugs, we work hard on priority 2 bugs, and tend to let 3's
and 4's slide.  The priority is set by committee when there is a
dispute.  (Of course, developers want to downgrade the priority so they
can say they have nothing to do.)

This kind of ranking becomes important at times like this when we are
attempting to release a product.  We agree that we will ship with no
priority one bugs, with a certain agreed upon number of priority 2's
and 3's and we tend to forget 4's unless there is nothing better to
do.

 


Reply to: