Re: Cloning of carried-forward JIRA issues vs. proposals

[robert_weir@us.ibm.com]

I think "affects version" is simply a fact.  What version(s) of the ODF 
specification does the issue apply to?  I don't think we need to get to 
CSD level granularity for affects version, except for newly reported 
issues in a public review cycle.  In other words, if someone reports an 
issue on ODF 1.2 CSD 07, and we agree to defer it, this does not mean that 
we must change affects to CSD 08, CSD 09 and then to ODF 1.3 CSD 01, CSD 
02, CSD 03, and so on every time we have a new CSD.   It should be 
sufficient that the issue is open.

But we do need some way of tracking which issues were covered by a given 
public review.  We tried a "component" in JIRA, and that didn't work well, 
and I got yelled at for that ;-).    So we've been using "affects version" 
for that.  But I think that granularity is only needed for public reviews.

For "fix version" we should record the exact CSD for each fix.  There is 
no downside to doing that.

A question for the TC is if we ever want to close any proposal, if after 
some period of time, no own agrees to take ownership of it.  We have many 
proposals from the pubic comment list that are in that category.  They are 
not defect reports, but more in line with "Wouldn't it be nice if...".  If 
the issues were closed, of course the could be reopened.  It is really the 
same thing either way.  The difference is whether we want the open/new 
issue count to accurately reflect the work remaining for us in a 
particular release, or whether we want that count to be inflated with 
unowned proposals. 

Also, now that we've done a complete cycle through JIRA, or nearly so, it 
might be worth writing down how we use it.  I'm not sure we used it 
consistently throughout ODF 1.2 (and the Errata), but I think we have 
enough experience with it now that we could codify how to use it. 

This could be put up on the wiki for example. 

-Rob



"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 04/28/2011 
03:52:45 PM:

> 
> I also don't think the rule about proposals needing an owner should 
> be applied to issues needing an owner.  Issues clearly need an owner
> to be resolved, but they certainly do not need an owner to be issues
> and open.  (How they get dealt with, and targeted to a CSD target is
> another matter.  I figured it was safe to target to 1.3 though.  I 
> chose 1.3 CSD01 because I had to pick one.)
> 
> It is true that the composite issue that I cloned, OFFICE-3680 is 
> tied to the original DeltaXML proposal that came in via office-
> comment as I recall.  However, the issue has a compilation of 
> related issues that remain to be resolved, however they came to be 
> deferred.  When I cloned it as applicable to ODF 1.2 and with 1.3 
> fix version, it was the issue aspect that was on my mind.
> 
>  - Dennis 
> 
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
> Sent: Monday, April 25, 2011 14:30
> To: robert_weir@us.ibm.com; office@lists.oasis-open.org
> Subject: RE: [office] Unnecessary cloning of JIRA issues
> 
> The reason I cloned that particular one (and maybe others, I forget 
> right now), is that a resolution was set and I didn't want to simply
> erase it (plus I didn't know how).  I have never tried the procedure
> Andreas suggests, and I think I had already clones the one of 
> interest by then.  Not sure.
> 
> In any case, there is a lot of commentary that may not be so 
> important and it would be useful to have a fresh sheet as well as a 
> link back to the old stuff.
> 
> If there is a different agreement, I will honor that.
> 
>  - Dennis
> 
> -----Original Message-----
> From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
> Sent: Monday, April 25, 2011 13:52
> To: office@lists.oasis-open.org
> Subject: Re: [office] Unnecessary cloning of JIRA issues
> 
> "Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca> wrote on 
04/25/2011 
> 04:19:05 PM:
> 
> 
> > Why are JIRA issues cloned rather than just retargetted? Cloning will
> > split the comments over the differnet issues and make it more 
confusing
> > to talk about them.
> > 
> > If the issue was resolved with a target, then cycling them through 
> > Resolved->Applied->Closed->Open will open them and allow a new target
> > and resolution to be set.
> > 
> > For example now we have two open issues 3312 and 3680 for exactly the
> > same issue. The clone 3680 is not needed.
> > 
> 
> In most cases it will be sufficient to simply re-target the issue by 
> setting a new "affects version".  I can imagine some less common 
> situations where an issue is partially addressed in ODF 1.2 with 
> completion in ODF-Next, but that is better handled via sub issues, to 
> preserve the connection.
> 
> In any case, I think the recommendation for ODF-Next issues was, that if 

> someone was interested in owning a particular issue, they should assign 
it 
> to themselves and set Affects Version to ODF 1.2 and Fix Version to one 
of 
> the ODF 1.3 CSD's.  For issues that do not have owners, we can let them 
> sit for now.
> 
> -Rob
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>