[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hyades-dev] Defect severity and priority



Richard,
Feel free to use any part of the defect process I did for AC tools. The
more similar they are the easier it will be for our area to follow them.


Thanks, Chris Knight
Rational Software, Autonomic Computing
IBM Toronto Lab
office: (905) 413 - 3447,  FAX: - 4920, TL: 969 -
cell: (416) 433 - 5449
mailto:knight@xxxxxxxxxx




                                                                           
             Richard                                                       
             Duggan/Toronto/IB                                             
             M@IBMCA                                                    To 
             Sent by:                  hyades-dev@xxxxxxxxxxx              
             hyades-dev-admin@                                          cc 
             eclipse.org                                                   
                                                                   Subject 
                                       [hyades-dev] Defect severity  and   
             04/05/2004 05:44          priority                            
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
                hyades-dev                                                 
                                                                           
                                                                           








I am starting to put together a series of topics that will help standardize
how defects and resources are managed within Hyades.  I will keep the scope
of each topic short to mitigate the amount of churn required to get closure
on a specific issue.

Topic I:  Defect Severity and Priority.

In the interest of standardizing how defects are categorized and tracked in
Hyades, I am proposing the following standard interpretation of defect
fields.   The development team will manage and address defects according to
these definitions.  The project management team will use priority and
severity to track the status of the project from week to week.  Defects
status will be addressed during the committer calls.

Severity
Severity is used to indicate the nature of the failure and impact to the
use case.  The more catastrophic the failure and greater the impact to the
use case, the greater the severity.  Severity categories are interpreted as
follows:

blocking - the use case cannot be completed with any level of workaround,
or the failure is catastrophic.
critical     - the failure is severe and can be avoided with some level of
workaround.  There must be some means of completing the use case, however,
the workaround is undesirable.
major      - hard failure, the use case can be completed with a minimum of
workaround.  There may be substantial performance problems.
normal   - soft failure, the main flow of the use case works but there are
behavioral or data problems.  Performance may be less then desired.
minor      - there is no failure, the use case completes as designed.  Fix
would slightly improve the use case behavior or performance.
trivial      - there is no failure, the use case completes as designed. The
benefits of a fix are cosmetic .

Priority
Defect priority indicates the impact to the project and/or the consumers of
the project.

P1 - this problem is directly impacting the ability of the consumer to
progress with the current driver.  A fix for this problem cannot wait until
the final week of the current iteration. Hyades will not  publish a
milestone driver without  a fix for this problem.
P2 - this problem needs to be fixed before the next milestone driver is
shipped.  Hyades will not  publish a milestone driver without  a fix for
this problem.
P3 -  it is desirable to have a fix for this driver before the completion
of the current iteration.  This fix will not stop a milestone driver from
being published
P4 - this defect should be fixed if time permits during the last two weeks
of the iteration.  A fix for this defect is not expected during the current
iteration.
P5 - this defect does not need to be addressed in the current iteration.


Next topic,  defect process, to follow shortly.

Feedback is welcome,


Richard K. Duggan
Problem Determination Enablement
IBM Toronto Laboratory
External: 905-413-2396
Internal: 969-2396

_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev