RE: [office] office-comment -> JIRA migration

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

Yes, I concur about resolution before subdivision, etc. 

However, I found that I was able to resolve a subtask before the main task,
and I was able to resolve the main task before a sub-task.  My confusion
about apply resolution was in not understanding what resolution means in
JIRA.  I've got it now.  Nevertheless, I agree that any initiation of
sub-tasks or splitting of issues should be done under the resolution of the
initial issue and not before.  

Moving a task to resolution can also involve creation of subtasks that
reflect individual applications of the relevant part of the resolution.  We
can even leave a subtask open if the main-issue resolution is to consider
that particular aspect later.  (I note there is a deferred state, but
haven't checked to see if that is appropriate as well.)

Also, as far as I was able to determine, resolution/application of the main
task/issue will still track any subtasks (that is, the connection is
maintained forever) and their separate progress, all comments, etc.

I think the key thing in helping my understanding is that resolution, in the
OASIS JIRA, is not completion, but agreement on what is to happen, with
application of the resolution (generally) being the final check-off.  That's
very useful.  It fits our work process for issues perfectly, and tracks all
the way to an issue resolution being reflected in specifications and/or
errata

I admire JIRA's arranging that the issues never really disappear and the
connection between subtasks and main tasks/issues is always preserved.
That's nifty.

 - Dennis

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
http://lists.oasis-open.org/archives/office/200905/msg00043.html
Sent: Friday, May 08, 2009 06:35
To: dennis.hamilton@acm.org
Cc: Michael.Brauer@Sun.COM; office@lists.oasis-open.org
Subject: RE: [office] office-comment -> JIRA migration

Thanks, from what I read the main annoyance is that an issue can have 
multiple versions assigned to it for the resolution, e..g, ODF 1.0 Errata 
02 and ODF 1.2, but the operations like apply resolution seem to act on 
the issue as a whole.  So if we want to independently track things that 
require fixes in more than one text, we need to do one of the following:

1) Enter independent issues for each target version, either by creating 
independent issues, or by cloning an existing one
2) Enter subtasks for each target version
3) Keep a single issue per issue, but only close it out when all relevant 
drafts have been updated

The important thing, I think, is to not split issues before a technical 
resolution is determined.  If we split things to early then you have two 
unresolved issues and risk arriving at divergent solutions to the same 
issue, expressed in different texts.  We don't want that to happen.  So 
I'm thinking that any splits (subtasks) should occur post-resolution.

What do you think?

-Rob

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 05/07/2009 
04:57:47 PM:
http://lists.oasis-open.org/archives/office/200905/msg00036.html


> 
> RE: [office] office-comment -> JIRA migration
> 
> Concerning subtasks and issue workflow, I was able to learn some things
> about workflow and the benign way sub-tasks and parent tasks move 
through
> stages independently and their connection is preserved.  I did this on 
the
> OIC TC JIRA, and my summary is at
> <http://lists.oasis-open.org/archives/oic/200905/msg00025.html>.
> 
> I'm not sure if all members of the ODF TC can browse the OIC TC JIRA, 
but
> those of us who are on that TC can do so.
> 
> I am more comfortable adding comments to issues that go with the public
> comments I am investigating.  It is not quite so visible as making new
> issues or sub-tasks of issues, although commenting seems to generate as 
much
> JIRA activity reporting to the ODF TC List as anything else.
> 
>  - Dennis 
[ ... ]