[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]