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: Discussion: Public Comment and Errata Urgency/Priority/Action Levels


In the time since we discussed severity levels, I have found that I am
uncomfortable attempting to apply the severity levels.

I would rather use is an indication of the priority/precedence/urgency that
we attach to a reported issue in terms of the action we propose to take.  I
am assuming that the issue passes categorization and it is agreed that the
matter discussed does occur (or there is a demonstrated likelihood of
misunderstanding that a repair could avoid).  

For me, this is different than attempting to create a template for inherent
severity, and more flexible.  That is why I am asking your impressions and
discussion on the list.

Here are suggested action levels.  Note that these can be assigned
differently with respect to the same issue but different versions of
specifications and in-progress development of committee drafts.  These are
assigned as the judgment of the TC on how to proceed with an issue.  This
seems to provide the discretion we require and that we can apply on a
case-by-case basis.

0. No Action.  Although the situation occurs, it is concluded that no action
is to be taken.

1. Elective.  The issue may be considered in work in progress; it is not
considered material and not worthy of errata or corrigendum to existing
work.

2. Desirable.  The issue will be addressed in work in progress.  It may be
reflected in a future errata or corrigendum, if such are being produced
anyway. 

3. Important.  The issue shall be addressed in work in progress.  It shall
be reflected in an erratum or corrigendum at the next opportunity.

4. Urgent.  The issue shall be addressed at the earliest possible time.  It
will be addressed in work in progress.  It is important enough to trigger
production of an erratum or corrigendum or advance notice of a defect to be
remedied. 

5. Critical.  There is an emergency involving risk to implementation and use
of a specified feature that must be addressed immediately.  Extraordinary
out-of-cycle measures will be taken to issue advisories and other
announcements of the issue and recommended work-around until it can be
handled as part of an urgent response.


 - Dennis



ADDITIONAL BACKGROUND

1. I chose to number lowest from 0 because it is easy to remember that 0
corresponds to "no action."

2. There may be a fine distinction between No Action and Elective.  In the
case of elective items, there is the possibility that there may be some
improvement in addressing the issue but it is left to the discretion of
those working on future materials.  This level is designed to ensure that
there is consideration, but there is no commitment with regard to the
outcome.  This is a place for severity level 5 items that are thought worth
considering but not required.

3. The "Critical" category is for some "the standard is on fire" situation.
I can't imagine what that might be, unless it is related to security issues
or a feature of the specification that is the target of some sort of exploit
or failure if implemented.  It is here just for completeness.

4. I tried fewer than 6 levels but I kept needing to put another back in
every time.

THE CURRENT SEVERITY LEVELS

[In my experience with defect/incident reporting systems, it is the
(external) submitter of an issue who assesses the severity level, not the
responding organization, which assigns priority and other disposition
categories.  It took me a while to notice that difference.]

Severity Levels as currently summarized on the Wiki
(http://wiki.oasis-open.org/office/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, severe 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. 

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
http://lists.oasis-open.org/archives/office/200903/msg00057.html
Sent: Thursday, March 12, 2009 10:01
To: office@lists.oasis-open.org
Subject: [office] 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:

[ ... ]

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

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



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