[edt-dev] Defect Guidelines for EDT 0.7.0

[Brian W Svihovec <svihovec@xxxxxxxxxx>]

We will be using the following guidelines
when opening EDT defects during the remainder of the 0.7.0 release:

Severity
* Blocker - The defect blocks execution
of a test scenario; Development work on the defect is blocked, usually
by another defect
* Critical - no useful work can be done;
permanent data loss; crashes; unrelated applications are killed; most common
operations fail consistently
* Major - a major function is experiencing
a reproducible problem which causes major inconvenience; common operations
fail consistently
* Normal - a fundamental function is
experiencing an intermittent problem; or a common operation sometimes fails;
a less common operation fails consistently.  Action to correct the
problem is necessary. 
* Minor - a less common operation fails
occasionally; all other errors.  Problems found are non-functional
and can be bypassed easily.  This includes (but is not limited to)
spelling errors, color problems, grammar problems, and incorrectly formatted
screens 

Priority [This can only be configured by a committer]
* P1 - These
defects must be addressed before the next general availability release
of the product.  P1 defects are serious enough that we would delay
a release to fix the defect.  Note that there may be exceptional cases
where a legitimate P1 defect will not be fixed in the release being shipped.
In such cases the Priority should remain at P1 and the defect should be
targeted to the next release.  All Critical defects are P1s (with
some rare exceptions) 
* P3 - These
defects have significant impact on users and their evaluation of the quality
of the product.  It is desirable to fix these before the next
general availability release but are not serious enough to consider holding
the release for a fix.  P2 defects are not candidates for patches.

* P5 - These defects should be tracked
and fixed when practical. Note that both Normal and Minor defects would
normally be rated P5. 

When opening defects, it is important
to remember that the Severity should be set based on the impact of the
problem, and not based on the importance of the fix to the release.  For
example, most, if not all, issues found in the MOFModel, Compiler, and
Generator components will have a Priority of P1, which means that they
must be fixed before 0.7.0 is shipped.  If a bug is found in one of
these components, but it is in an area of the language that is not commonly
used, or if the issue can be easily worked around, the Severity of the
defect should be set to Normal.

-Brian