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: Re: [office] Discussion: Public Comment and Errata Urgency/Priority/ActionLevels


Dennis E. Hamilton wrote:
> Hi Peter,
> [...]  There are other deficiencies, but I don't suppose to go into battle over that.

Thanks :-)

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

Sounds reasonable.


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

I totally agree here. It's probably more effective to adopt ourselves to
the JIRA 'priorities', which seem match our requirements for the most
part, rather than starting a long discussion on the perfect mapping.

Best regards,

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

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


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

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