Reference-ID: formal-aspects-meeting-minutes-v1-20130201 Version: 1.0-20130201
Action items are referenced by their local ID as generated by the Kavi-Tool upon creation. This ID consists of the constant string AI# and an automatically incremented number padded to the left with zeros and to 4 digits like eg. AI#0123.
The ownership of action items is noted
[owner: Given Family] and as indicated by the AI-List-Tool. Additionally the time stamp of retrieval is given in the preamble. The list of open action items (before the meeting) may be documented in an appendix esp. in longer minutes to help the reader foxus on the actual progress being made during the meeting.
The linkage to the documentation of an action items specific state progression inside meeting minutes SHOULD be provided through a publicly accessible URL of the meeting minutes. To ease the navigation for the reader this link MAY have a fractional part which is the lowercased action items ID where the ’#’sign has of course been stripped. For meeting minutes this fractional target is guaranteed to point to the relevant subsection of the minutes.
As an example, for linking the action item AI#0005 to its state progression (from ‘Ongoing (Note: Due 2013–01–10)’ to ‘Ongoing (Note: Due 2013–01–31)’) during meeting#20 the specific public URL is (fractional part=’ai0005’):
Issues are referenced by their local ID as generated by JIRA upon creation. This ID consists of the constant string ODATA- and an automatically incremented number like eg. ODATA–123. The list of processed issues may be documented in an appendix esp. in longer minutes to help the reader focus on the actual progress being made during the meeting and as a navigational support. If such an index is provided, it will have at most two main parts: First come the public comments (if any), second the JIRA issues. Each list of issues is sorted by ascending issue number. Noted are the ID, the summary and the reference to the relevant subsection where the issue progression has been documented.
We minute an issue state progression as an ordered triple consisting of:
The rationale behind this is: a) to document the initial status - which may well deviate from the (tentative) status set inside the instance in JIRA at that time, b) to optimize the transfer of changes resulting from the discussion back into the issue’s instance inside JIRA (if dictated by the accepted motion) and last but not least c) to ease the lookup for the reader.
The value of the main status is one (and only one) from the set (New, Open, Deferred, Proposed, Resolved, Applied or Closed) as documented in “Best Practices for Issue Handling”, where the states and transitions are further explained as they have been adopted by the TC.
A step by step recipe on how to apply these resolutions to new revisions of work products is given in “How to Apply Resolved Issues” and shall assist the editors performing the many formally necessary (but often purely mechanical) steps needing attention along the way.
For the purpose of this section any issue that results in an implemented change will be considered a ‘mainstream’ issue. The typical lifecycle of such an issue and with focus on the relation between actions, status and documentation in meeting minutes may be illustrated as:
The relation of incoming and outgoind issues states is further listed and explained in the following subsection. Any remaining details on available issue states and transitions may be found in “Best Practices for Issue Handling”.
The issues that are put on a TC meeting agenda MUST have one of the three following incoming states:
For each of those incoming issue states, the corresponding possible outgoing states - amended with explanations (noted in parentheses) - are:
The linkage from the representation of an issue as noted in JIRA to the documentation of its specific state progression inside meeting minutes SHOULD be provided through a publicly accessible URL of the meeting minutes. To ease the navigation for the reader this link MAY have a fractional part which is the lowercased issues ID. For meeting minutes this fractional target is guaranteed to point to the relevant subsection of the minutes.
As an example, for linking the issue ODATA–13 to its state progression (from New to New+Proposed) during meeting#20 the specific public URL is (fractional part=’odata–13’):
The corresponding private URL (only visible to TC members) would be:
As we tend to keep the filenames persistent, one can usually build the public from the private URL by
Thereby we maximize the public navigation experience throughout our documentation.
If an issue created in JIRA is related to a public comment (eg. because it has been accepted as an issue by the TC) the subject of the JIRA issue should follow the format as described in section [3.2].
Public comments are referenced by their local ID pair as generated by the OASIS mailing list archiver upon receipt. The derived ID consists of the string literal c the ‘YYYYMM’ string from the year month folder, the string literal e and automatically incremented number padded to the left with zeros and to 5 digits like eg. c201301e00001.
Abiding the rules of OASIS all comments are acknowledged and considered. So every comment received through the single entry point odata-comment will be reflected in one or more meeting minutes.
The linkage from the representation of received comment as noted in the public comment archive rooted at https://lists.oasis-open.org/archives/odata-comment/ to the documentation of its specific processing inside meeting minutes SHOULD be provided through a publicly accessible URL of the meeting minutes. To ease the navigation for the reader this link MAY have a fractional part which is the derived ID as described in section . For meeting minutes this fractional target is guaranteed to point to the relevant subsection of the minutes.
If a comment results in an issue created in JIRA the subject of the issue should indicate this by appending the string literal (public comment $ceID) with $ceID being replaced with the commentEntryID as described in section  (cf. [sample] below).
It is also beneficial, if the description of the JIRA issue starts with text following the pattern:
The public comment [$ceID](https://lists.oasis-open.org/archives/odata-comment/$yearMonth/msg$entryID.html) with title "$subjectOrTitle" indicates, ...
As a sample, the first comment received, resulted in issue ODATA–232 with the summary:
“Enhance description of normalization procedures (public comment c201301e00001)”
and the description:
“The public comment c201301e00001 with title ”Query String parsing in URIs“ indicates, that the description of normalization procedures in the ABNF Construction Rules can be enhanced.”.