Using JIRA

[robert_weir@us.ibm.com]

A quick update on JIRA, and some thoughts on how we can use it.  Although 
we could sit down and define an elaborate formal process, I don't think 
that is necessary or desirable at this point.  We're replacing an informal 
process that involved a number of mailing lists and a spreadsheet and a 
wiki with an informal process that involves JIRA.  Let's migrate what we 
have over to the new technology.  Then, if we want to adopt a more formal 
process, we can discuss that.  But we're not obligated to adopt a more 
formal process merely because we're moving to JIRA.  These are two 
separate decisions.

The following are a list of issue sources, along with my recommendations 
on how we should deal with them:

1) Legacy comments on the office-comments list.  I've migrated them all 
over to the JIRA already.  This includes "real" comments that we should 
discuss and resolve, as well background chatter on the comment list that 
we can ignore. 

I'm in the process of closing all migrated comments that are not real 
comments.  In some cases this can be done in bulk.  For example, all items 
from the comment list where I am the author are not real comments and have 
been closed.

2) Existing assignments and dispositions from the "Registry of Comments" 
spreadsheets.  I will note each of our prior decisions in the 
corresponding issue in JIRA.  So if something was noted as "Michael will 
investigate" then I will open the issue and assign to Michael.  If we said 
that something would be addressed in the next ODF 1.0 Errata, then I will 
open the issue and assign ODF 1.0 Errata and ODF 1.2 (if appropriate) as 
the target releases.   Comments that came in during the ODF-Next call for 
proposals will be assigned to ODF-Next.

Note that the two Japanese Defect reports are already in the spreadsheet, 
so they will be reflected in JIRA by this step.

3) New comments from the comment list.  Periodically, perhaps monthly for 
now, more frequently during public review periods, I will migrate over 
comments from the public comment list.  If we can keep discussion on that 
list to a minimum, then we'll get less "junk" in JIRA.  I think we want to 
get into the habit of commenting on comments within JIRA, adding new 
information in JIRA, etc., so the JIRA record reflects the most-complete 
and current state of the issue.

4) Legacy member proposals from the TC's wiki.  
http://wiki.oasis-open.org/office/List_of_Proposals

This is the consolidated list of proposals which TC members made last 
November.  Some of these made it into ODF 1.2 when we voted in December. 
We said that the remainder would be deferred to ODF-Next.  I will enter a 
JIRA issue corresponding to each of these deferred proposals so we don't 
lose track of them.

5) Legacy member comments.  If you have a comment on the ODF 1.2 draft 
that has not yet been addressed in CD 02, and it is not already recorded 
via one of the above mechanisms, then please enter it as a new issue in 
JIRA, so we can track it to resolution.  I do not plan on scouring the 
list archives to find these issues.  So if you want something addressed, 
then you will need to add it yourself to JIRA.

6) New member comments.  If any member has other proposals or comments on 
the text, please create an issue for it in JIRA.  Even simple 
typographical errors are best tracked in JIRA.  There is no need to send a 
separate email to the TC when you create a new JIRA issue, since an email 
will be sent automatically.

7) New Defect reports from SC34. I will transcribe any new defect reports 
we receive from SC34  into JIRA.

8) Subcommittee issues.  If any subcommittee has a list of issues that 
they have been reporting on their lists, they need to find a way of 
getting them into JIRA.  This mainly applies to the OpenFormula SC. 

Are there any other sources of issues that we need to deal with?  I know 
Patrick has some issues he is tracking in the text of the draft, as 
editor's notes.  I'll leave to him whether we wants to transcribe those 
into JIRA or not. 

Regards,

-Rob