OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Defect severity


It is probably worth getting to a common understanding of defects and how 
much we're going to commit to resolving for ODF 1.2.  OASIS doesn't 
mandate any particular taxonomy for defects, and ISO/IEC has only a 
technical/editorial two-bucket classification system which is a bit too 
course for our needs.

I'll toss out this classification scheme for defects, a scale of 6 
severity levels:

0. Defects which could cause the standard to be used in ways which are 
unsafe to persons or the environment, or which violate civil or human 
rights.  For example, defects related to privacy, safety tolerance, 
encryption, etc. 

1. Defects whose existence would likely cause direct business or financial 
loss to users of the standard.  For example, spreadsheet financial 
functions which are defined incorrectly,

2. Defects which prevent the standard from being used in the way which it 
was intended.  This severity level requires a likelihood of misapplication 
of the standard, not merely a remote potential for misapplication. 

3. Defects which violate drafting requirements from OASIS or ISO/IEC.  For 
example, lack of a scope statement or misuse of control vocabulary.

4. De minimis defects , i.e., trivial defects, hardly worth fixing. 
Obviously, even the smallest defect related to health and safety must be 
given considerable regard.  However, a typographical error where the 
meaning is otherwise clear from the context may be considered trivial. 
Similarly, a grammatical error which does not change the meaning of a 
clause or a terminology question where the meaning is clear and 
unambiguous to a person having ordinary skill in the art to which the 
clause most closely pertains, i.e., 2D vector graphics.

5. Matters of personal style.  For example, a request to use "do not" 
rather than the contraction "don't".  These are opinions, but not defects.

Obviously the above are not rigid mathematical definitions.  Most are 
judgement calls.  We are fortunate to have so many ODF implementors on the 
TC to help us accurately evaluate defects and set appropriate severity 
levels.

If something like the above meets with the TC's approval, then we could 
elaborate on the definitions and agree to apply them in our decision 
making. 

For example, we could say that defects reported on published ODF standards 
would be processed as follows:

Severity 0-1 would trigger the TC to immediately prepare an errata 
document.
Severity 2 would be resolved in the next-scheduled errata document.
Severity 3-4 will be resolved in the next technical revision of the ODF 
standard, i.e., pushed into the next version.

We could also agree to treat this severity levels differently depending on 
where we are in the drafting process for ODF 1.2.  For example, once we 
send out for public review, we might commit to fix all defects of severity 
0-3, but not 4 & 5.

Let me know if this is is a useful model for thinking of defects.

-Rob


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]