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