[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Tying issues to committee drafts
I'm good with using filtering on some agreed scheme in order to determine the applied resolutions that roll-up into a given cd (rev). Help me out with the nomenclature a little bit. Typically, an issue is against a given current draft (or a whole sequence up to and including the given current draft). So resolution would seem to be against that current draft, but found to be applied in a subsequent draft. Or is the agreement on resolution that such-and-such action be taken in some targeted draft/spec, and application is the declaration that the action occured, whatever draft/spec it appears in? (My limited practical experience suggests that this may be more realistic.) Or are there up to three parameters: (1) where the defect is noticed or the suggestion is seen to apply, (2) where the resolution stipulates a change (if any), and (3) where the resolution is effected. (Just trying to get my head around how to consistently understand use of the JIRA "resolved" and "applied" states.) - Dennis -----Original Message----- From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] http://lists.oasis-open.org/archives/office/200906/msg00031.html Sent: Tuesday, June 02, 2009 09:25 To: office@lists.oasis-open.org Subject: RE: [office] Tying issues to committee drafts "Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 06/02/2009 12:03:27 PM: http://lists.oasis-open.org/archives/office/200906/msg00029.html > > RE: [office] Tying issues to committee drafts > > I'm confused. I thought cd02 (aka cd01 rev06) is what we are currently > reviewing and we will likely see cd02 rev01, cd02 rev02, etc., until we > decide to declare one of them cd03. That was the pattern in moving from > initial cd01 to declaration of cd02. > That is the pattern that OASIS asks us to follow. We have revisions of a CD until the new CD is approved, etc. > I assume that you apply a resolved issue (in JIRA parlance) when you have > actually made the changes to the draft (revision) you are working on. > Although technically, it would not be fully applied until it survived into > an approved cd? > I think that is the intent. JIRA is for tracking issues. It is not an approval mechanism. Meeting minutes are for recording what the TC approves or doesn't approve, and these decisions for the most part are batched into CD approval votes. The main thing we want JIRA to track is the textual emendation of the current working text to include the stated resolution of the issue. What would help is if Patrick (or anyone else resolving issues) would note what revision a particular issue is resolved in. Right now I have "releases" for ODF 1.2. I could define releases for ODF 1.2 - CD02Rev6, CD02Rev7, etc. Or we could just track that information in the comment field as we go. [ ... ] > (2) we understand that a cd includes all changes applied to intermediate > drafts since the previous cd (including any reversions/replacements of > changes) > > It might come down to how filtering works best? > I think we have (2) above. The JIRA filtering mechanism should allow us to filter on release = ODF 1.2 to produce a master list of changes, or to do a free-text search in the comment fields for a particular CD revision if we care to track that. For example, we should be able to produce a list of all issues fixed in ODF12-Rev6. -Rob > - Dennis > > -----Original Message----- > From: Patrick Durusau [mailto:patrick@durusau.net] http://lists.oasis-open.org/archives/office/200906/msg00018.html [ ... ]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]