Re: [office] Discussion: Public Comment and Errata Urgency/Priority/ActionLevels

[Peter Junge <peterjunge@RedOffice.com>]

Dennis, all,

I would go for action levels, that represent the priorities
predetermined by the JIRA bug tracker, in order to ensure consistent
work flow.
Starting at 'Create Isuue' [1], I have been proceeding to step 2, where
I find 'Blocker/Critical/Major/Minor/Trivial' on the 'Priority'
drop-down. Both your proposal and the severity levels defined at the ODF
wiki [2] fail in mapping to the 'Create Issue' form, because they break
severity down into six levels, rather than five predefined in the bug
tracker. This seems to be configurable with JIRA [3], however I would
guess, that tweaks have a global effect on the JIRA installation at
OASIS. Did someone dive deeper into this yet?

Best regards,
Peter

[1] http://tools.oasis-open.org/issues/secure/CreateIssue!default.jspa
[2] http://wiki.oasis-open.org/office/Severity_Levels
[3] http://www.atlassian.com/software/jira/docs/v3.13.1/priorities.html

Dennis E. Hamilton wrote:
> 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 
> 
> 
> ---------------------------------------------------------------------
> 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 
> 
> 

-- 
Peter Junge
Open Source Strategy Director

Beijing Redflag Chinese 2000 Software Co., Ltd.
Building No.2, Block A, Huilongsen, 18 Xihuan Nanlu
Beijing Economic-Technological Development Area
100176 Beijing - P.R.China

北京红旗中文贰仟软件技术有限公司
地址：北京经济技术开发区（亦庄）西环南路18号汇龙森A座二层
邮编：100176

电话/Tel: +86-10-51570010 ext.6183
邮箱/e-mail： peterjunge@RedOffice.com
http://www.RedOffice.com