RE: [office] Discussion: Public Comment and Errata Urgency/Priority/Action Levels

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

Hi Peter,

The JIRA Priorities are clearly defined around software deliverables and also support after deployment.  There are other deficiencies, but I don't suppose to go into battle over that.

I do recommend that we come up with an understanding of these level that correspond in clear-cut ways to creation of specifications and documentation of other kinds.  Likewise, we need to understand how to calibrate the importance of responding to defect reports on that scale.

I don't have any specific recommendation.  We should think it over.

 - Dennis

MORE BACKGROUND

My first thought was that the action/urgency levels I had in mind interleaved around the five JIRA "priorities."

I now see it is more complicated than that.  First the JIRA priorities are not priorities ("trivial" is not a priority) and the tool-tips that go with them reveal even more about them as being judgments about the issue.

"Blocker" is an interesting one, and it applies to in-progress work, of course.  I can see ways to use that.

Here's a crude mapping (very crude, I am just playing here):
    Urgency	     JIRA Priority    Severity

0: no action (an actual resolution in JIRA)
                 trivial        5: matter of style 
                 (cosmetic)     4: de minimis
1. elective
                 minor (can workaround)
2. desirable                    3. mandated
3. important                    2. insufficient 
4. urgent        major          1. serious
                 (loss of function)     
5. critical      critical       0. critical
                 (fails)
                 blocker  
                 (cannot proceed)   

You can slide the Urgency and Severity notions around the JIRA Priorities in different ways.  I'm not going to fuss over that.  I think making something sensible about the JIRA Priorities that work for us in terms of urgency and level of response is good enough.

-----Original Message-----
From: Peter Junge [mailto:peterjunge@RedOffice.com] 
http://lists.oasis-open.org/archives/office/200904/msg00086.html
Sent: Monday, April 27, 2009 19:28
To: dennis.hamilton@acm.org
Cc: robert_weir@us.ibm.com; office@lists.oasis-open.org
Subject: Re: [office] Discussion: Public Comment and Errata Urgency/Priority/Action Levels

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:
http://lists.oasis-open.org/archives/office/200904/msg00085.html
[ ... ]
> 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.
> 
> 
[ ... ]