[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: "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: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]