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,

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

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

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

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


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