Re: [tab] Draft: proposed process for comment handing

From
Chet Ensign <>
Date
2012-12-20T16:11:14+00:00
ID
CAAwgnnNO=
Thread
Re: [tab] Draft: proposed process for comment handing
Yes, I had the same thought. I suppose it could read that the point at which the TC wants to take the next action is deemed to be the end of the previous review period. What I wanted to avoid was the situation where the TC doesn't start its next public review for 6 months and then has to go back and put the log together. But I suppose if a group puts themselves in that situation, they have only themselves to blame. 

On Thu, Dec 20, 2012 at 10:40 AM, Martin Chapman <> wrote:

Chet,

2d) says:

"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.

Sometimes it takes longer than four weeks to resolve all the comments, so I would be reluctant to hard wire a time limit.

I think it is only necessary to say that as a pre-condition for  another public review or to order progress to a committee spec/note is that the document with the stated info is provided.

Martin.

>-----Original Message-----

>From: Chet Ensign [mailto:]

>Sent: 20 December 2012 00:02

>To: 

>Cc: ; TCA

>Subject: [tab] 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

-- 

/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