Rob, that is an excellent question/point. "Comment" needs a definition.
First let me say that I agree that tracking all comments, whenever received, is good practice. I would never try to dissuade a TC from doing that. Here, though, I am just trying to stick to the requirements set forth in the TC Process and find a way to satisfy them.
Since the term is not formally defined in document -- perhaps it should be -- I have to derive a definition from a reading of the text itself.
The document describes the requirements for handling comments in three places: section 2.2, TC Formation where it deals with comments received during the call for comment period, 3.2 Public Review of a Committee Draft where it says that comments must be acknowledged, etc. and 3.4.2 Public Review of a Candidate OASIS Standard where it again says acknowledge, track, etc.
Since in each case the requirements are set out in a section dealing with public reviews, my definition of comment is "a statement received in an email to a TC's -comment@ mailing list or, in the case of a TC member, in an email to the TC's primary mailing list during an announced public review period that refers to the work product under review." That is admittedly a pretty narrow definition but it is what I infer from the text. I'm happy to consider other definitions.
So that means that a comment on ODF 1.2 that comes in during a public review of ODF 1.3 can be (not must be, just can be) left out of this process. It means that a generic comment, perhaps about the scope of the TC's work or a question about an interpretation of something in another document, can be left out of this process. And it means that a comment provided by voice in a meeting or added by a member to the TC's JIRA project can be left out of this process. Of course, it also means that an incomprehensible rant to the -comment@ mailing list does count and must be acknowledged and disposed of if it is about the document under review.
And, in the edge case that we had, for example, some drunken idiot spamming the comment list with gibberish about ODF 1.3, I'd work out a solution with you.
I am fine with the TC using his/her discretion on what qualifies and what doesn't.
/chet
On Thu, Dec 20, 2012 at 9:11 AM, <> wrote:
It would be good to clarify what a "comment"
is.
Is every post to the comment list a
"comment"? Even if the post does not relate to the draft
under review? Even if it is a response to another post that does
not itself raise an issue? Even the occasional post from a TC Admin
(https://lists.oasis-open.org/archives/office-comment/201211/msg00001.html)?
What we've done with the ODF TC is transcribe
into JIRA the essence of any post to the comment list that is actually
a comment from a non-TC member on the specification. We do this for
comments received anytime, for any revision of the specification. So
if we're doing a public review for ODF 1.3 and we get a comment on ODF
1.2, we'll track that as well. But the Chair uses his discretion
to determine what is and what isn't a comment. Presumably we elect
Chairs, in part, for their judgement.
Regards,
-Rob
From:
Chet Ensign <>
To:
,
Cc:
,
TCA <>
Date:
12/19/2012 07:25 PM
Subject:
[chairs] Draft:
proposed process for comment handing
Chairs,
I will circulate this to the broader membership after a review with you.
Last April, I opened a conversation about how to enable the OASIS requirements
for handling comments to be met while minimizing the procedural impact
on TCs. (The thread started here: https://lists.oasis-open.org/archives/chairs/201204/msg00020.html)
The observations and insights offered were valuable. This email lays out
the next step towards implementing a consistent process.
Below is my proposal for a procedure that I think meets the consensus from
that conversation to (a) keep it simple, (b) provide options while (c )
meeting the TC Process requirements. I have attached a couple of sample
templates based on the samples offered that could be used to record comments
and their dispositions. Use of these won't be required, they will just
be provided for the convenience of the TCs that want something to use as
a starting point.
Please have a look at this over the next few weeks and share your thoughts
with me. I will ask for broader feedback in January with a goal of documenting
this, announcing it and then putting it into practice on or about February
1st. Note that the procedure will not be retroactive - it will apply to
work started from its effective date forward.
To be clear, this changes nothing about the current requirements documented
in the TC Process. This simply provides a consistent means for TCs and
TC Admin to work together to meet the requirements - something that has
been lacking to date.
1. TC Obligations With Respect to Comments
The requirements for handling comments are laid out in sections 2.2, 2.8,
3.2 and 3.4 of the OASIS TC Process. Those requirements are:
- That comments be received only through the TC's <short name>-
mailing list.
- That comments be received by one or more members of the TC including
the chair.
- That comments be acknowledged.
- That comments be tracked and their resolutions documented:
a) During a proposed TC call for comment period;
b) During a public review of a TC work product;
c) During a public review of a Candidate OASIS Standard.
- And that at the end of the comment / review period, the TC post to its
email list an account of each of the issues raised during the public review
along with its resolution.
2. Proposed Procedure for Meeting These Obligations
Here are the proposed steps for a TC to take to meet the requirements.
a) The TC Chair, at a minimum, must subscribe to the TC's <tcname>-
mailing list. It will likely make sense for another TC member (e.g. secretary,
editor) to be assigned to subscribe to the list and track and report comments
and issues back to the TC.
b) Someone from the TC must acknowledge that the TC has received the comment
by sending an email acknowledgement to the provider. A simple "thank
you for your comment; the TC will be consider it" message is sufficient.
c) The TC must track each comment received and how the group decides to
resolve it. Per the TC Process, a TC is not required to take any action
on the substance of the comment, but the decision not to must be recorded.
The TC can choose to track comments and resolutions however they wish:
in a word processing document, in a spread sheet, in JIRA, in the TC wiki.
The TC must at a minimum record:
+ The date the comment was received;
+ A link to the email in which a comment was received;
+ The name of the person or entity providing the comment;
+ A brief summary of the comment;
+ A statement of the TC’s decision on how to handle the comment, in as
much detail as the TC wishes to provide.
In the event that a single email provides multiple comments or issues,
each must be listed, tracked and resolved separately.
The list need not be cumulative however keeping a cumulative list is likely
to be more convenient when the time comes that you want to submit a Committee
Specification as a Candidate OASIS Standard. The TC Process states that,
before an OASIS membership ballot can be held on a COS, the TC must provide
"a pointer to an account of each of the comments/issues raised during
the public review period(s), along with its resolution." Having all
the comments and their resolutions stored in one list will make satisfying
this requirement easy.
d) Four weeks after the end of a public review will be deemed "the
end of the review period." By this point at the latest, the TC must
post to its email list a document containing, at a minimum, the pieces
of information listed above. The document can be either a word processing
document or a spread sheet but it must be a document that can be opened
and read by any interested party.
If the TC is using JIRA or some other means to track comments, a document
must be created by exporting the information from that source.
If the document is a cumulative list of comments and resolutions, it should
also contain, for each comment, identification of the draft to which it
applied.
The posting email can be created by loading the document into the TC's
document repository and using the automatically generated email to produce
the pointer or by attaching the document directly to the email.
With that email, the TC obligations will be considered fully met.
3. What TC Administration Will Do With the Comment Resolution Document
A key objective here is to ensure that comments and their resolutions can
readily be found by other who are interested in the TCs work. Here is what
TC Admin will do with the documents.
a) When the TC is ready to take another action on its work product (e.g.
request another public review, request a ballot to approve a Committee
Specification), a pointer back to this document will have to be provided
as part of the support request. TC Administration will not proceed with
a requested action until the comment resolution document is provided.
b) A link to the comment resolution document will be included in the announcements
of subsequent public reviews, document approvals, Special Majority ballots
and other communications where it will provide additional, useful information.
c) The comment resolution documents will also be stored in the OASIS Library
along with the public review drafts to which they apply. This will help
to ensure transparency and traceability between comments received during
a public review and their resolution.
Thanks very much for your feedback and help putting a process in place.
My best wishes to you all for happy holidays.
Best regards,
/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393
[attachment "draft-comment-resolution-list.xls" deleted by Robert
Weir/Cambridge/IBM]
[attachment "draft-comment-resolution-list.odt" deleted by Robert
Weir/Cambridge/IBM] [attachment "draft-comment-resolution-list.ods"
deleted by Robert Weir/Cambridge/IBM] [attachment "draft-comment-resolution-list.doc"
deleted by Robert Weir/Cambridge/IBM]
--
/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393
Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html
TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin
Follow OASIS on:
LinkedIn: http://linkd.in/OASISopen
Twitter: http://twitter.com/OASISopen
Facebook: http://facebook.com/oasis.open
