[hyades-dev] Defect severity and priority

[Richard Duggan <rduggan@xxxxxxxxxx>]

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