[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tab] Draft: proposed process for comment handing
Chet,
2d) says:Sometimes it takes longer than four weeks to resolve all the comments, so I would be reluctant to hard wire a time limit.
"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.
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:chet.ensign@oasis-open.org]
>Sent: 20 December 2012 00:02
>To: chairs@lists.oasis-open.org
>Cc: tab@lists.oasis-open.org; 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>-
>comment@lists.oasis-open.org 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>-
>comment@lists.oasis-open.org 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]