OASIS Open Document Format for Office Applications (OpenDocument) TC

  • 1.  Cloning of carried-forward JIRA issues vs. proposals

    Posted 04-28-2011 19:53
    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


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

    Posted 04-29-2011 00:10
    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


Related Content