On 03/12/09 18:01, robert_weir@us.ibm.com wrote:
> 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.
+1 from me for the categories. Having defect categories will in any case
help us to prioritize or work and will help us to process the many
comments that we receive.
The categories you are proposing may not cover all cases, and one could
think of many other criteria for assigning categories, but I think what
is essential is that we have categories at all, so that we don't have to
discuss for each comment individually how to proceed with it.
>
> 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.
In principle I agree to this, too. But I would suggest that we check how
the categorization works in practice before we commit to bind particular
actions to them.
So, what I suggest is that we categorize the comments/defect as you have
suggested. If we have categorized all of them, then we may check if the
result of assigning particular actions to the categories still appears
to be reasonable to us. If yes, we seem to have found a good
classification. If that is not the case, for instance because we would
not resolve issues in an errata where we feel they should be resolved or
vice versa, then we may reconsider the categorization.
Best regards
Michael
>
> Let me know if this is is a useful model for thinking of defects.
>
> -Rob
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
--
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH Nagelsweg 55
D-20097 Hamburg, Germany michael.brauer@sun.com
http://sun.com/staroffice +49 40 23646 500
http://blogs.sun.com/GullFOSS
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering