Comment on new Public Review Requirement was RE: [chairs] Draft Jan2009 TC Process changes summary

[Harold Lockhart <hal.lockhart@oracle.com>]

I would like to suggest that the BoD reconsider the change to require public review after any change to a spec.

I understand the intent is to have a simple, clearcut rule which creates more openness and prevents anyone from "sneaking" changes thru. However I fear that the change will have the opposite effect.

For example, a public review would be required for changes such as additions or subtracton of entries in the acknowledgements, any change of affiliation of anyone listed (they are still trying to stamp out all the BEA references), misspellings and formatting errors. 

Currently there are public reviews announced almost weekly. I am concerned that a potential poliferation of "null" reviews will have the effect of discouraging people from paying careful attention to reviews where real technical changes have been made.

Hal

> -----Original Message-----
> From: Jeff Mischkinsky 
> Sent: Thursday, January 07, 2010 10:45 PM
> To: chairs@lists.oasis-open.org
> Subject: [chairs] Draft Jan 2009 TC Process changes summary
> 
> 
> Hi,
> 
>    The Process Committee is proposing some additions and 
> modifications  
> to the TC Process and is soliciting feedback and comments on this  
> "almost" final draft. I've tried to summarize the major and minor  
> changes in this email, but you should read the real docs 
> (attached) if  
> you'd like to see the detailed changes.
> 
> A major focus of the Process Committee for the last two years 
> has been  
> to add a "non-standards TC approval" track to the process. 
> There were  
> conflicting requirements involving trade-offs between IPR Policy,  
> approval processes, reviews, etc. The result which you see 
> before you  
> is not quite as delicate a compromise as that surrounding the 
> current  
> US health care debates, but its close. :-) I've broken down the  
> changes into 3 major components, but please keep in mind that they  
> interact with each other, and that they are intended to work 
> together.  
> (I've always wanted to use the phrase "synergistic changes" 
> but i will  
> refrain.)
> 
>    The plan is to consider these changes at the next Board 
> f2f meeting  
> at the beginning of February, so we'd like to have feedback and  
> comments available by January 25 ( a week or so before the Board  
> meeting) so that they can be considered by the Process Committee and  
> the Board.
> 
>    Attached you will find a redline showing the changes from the  
> current policy, and a clean copy. The current policy is on the OASIS  
> web site.
> 
> Thanks and appreciation are due to Mary McRae (the OASIS TC 
> admin) for  
> a yeowoman's job in editing the TC Process doc, and keeping up with  
> the various gyrations, drafts, and proposals that the Process  
> Committee have produced, debated, thrown away, and finally settled on.
> 
> Disclaimer:  Also please note that this email is MY attempt, as TC  
> Process Chair, to describe the changes and has not been formally  
> approved by the TC Process Committee. (And I'm sure its members will  
> chime in with their own comments if they are so moved. ;-)
> 
> cheers,
>    Jeff Mischkinsky, Chair, OASIS Board TC Process Committee
> 
> 
> MAJOR CHANGES:
> ==============
> 
> PUBLIC REVIEW REQUIREMENTS FOR TC LEVEL APPROVAL (Section 3.2 
> and 2.18  
> A)
> ------------------------------------------------
> The Public Review requirements for TC level approvals have been  
> simplified and streamlined, partially to accommodate the 
> addition of a  
> non-standards track.
> Basically the minimum for initial public review will be 30 
> days (down  
> from 60 days) with subsequent reviews being at least 15 days. ANY  
> changes made after a review closes must be submitted again 
> for public  
> review.
> 
> Section 2.18 has been split to distinguish between Committee 
> Spec (no  
> change) and Committee Notes (new)
> 
> 
> COMMITTEE NOTES aka "non-standards track work product", aka "info  
> docs"  (Section 2.18 B and 3.3)
> ---------------
> The Process Committee has been working for almost 2 years to add a  
> "non-standards" TC approval track.
> 
> The basic idea is that we've added a means whereby TC's will be able  
> to approve as a Committee Note any material that is not 
> intended to be  
> a standard. These could be primers, explanatory material, best  
> practices (how to use a standard), presentations/papers, test 
> suites,  
> etc., that can be "officially" approved as representing the views of  
> the TC, etc. They will be covered by the IPR policy. The 
> mechanics of  
> the approval process are the same as for a Committee 
> Specification so  
> that there is no incentive to classify something as standards track  
> vs. non-standards track because one is easier to get approved, i.e.  
> can't "game the system".
> 
> A non-standards track work product stops at the Committee 
> Note level.  
> Therefore it may NOT be put up for an OASIS-wide vote, unlike a  
> standards track work product, nor submitted to an outside (de jure)  
> body.
> 
> Committee Notes will have different templates, cover pages, etc. to  
> distinguish them from specifications/standards. They are not 
> intended  
> to be normatively referenced by other standards (either inside or  
> outside of OASIS), though of course there is no way to actually stop  
> someone from doing so (hence the IPR safeguards and rigorous review/ 
> approval process).
> 
> A TC can choose to "re-target" a work product by deciding to switch  
> templates and going back to the CD stage.
> 
> Section 2.18 B, which is new, describes the required parts of  
> Committee Note. Essentially they are the same as for Committee Specs  
> except that a Conformance Clause (B1) and external files for  
> programming language artifacts (B5) are optional.
> 
> OASIS STANDARD APPROVAL PROCESS (Section 3.4)
> -------------------------------
> The process from going from Committee Spec to OASIS standard 
> has been  
> modified. We've identified a new state for a Committee Spec 
> that a TC  
> wishes to advance to OASIS Standard, called a Candidate OASIS 
> Standard  
> to clarify things.
> 
> The main change is to now require a 60 day public review of the  
> Candidate OASIS standard, to ensure that OASIS standards that are  
> submitted for international (de jure) standards processing 
> meet their  
> review requirements.  This replaces the "familiarization 
> period" under  
> the current policy. Candidates may now be submitted at any time (not  
> just once a month) and TC admin now has at most 15 days to complete  
> processing and start the Public Review.
> 
> Once the public review has completed, there are now shortened  
> timelines for conducting the subsequent approval votes. The possible  
> outcomes of the public review (no comments, comments but no changes  
> made as a result, changes made as a result) and the subsequent  
> processing rules have been clarified.
> 
> Note: The minimum time lines for the public reviews and votes should  
> be approximately equal to get to OASIS standard and shorter for  
> Committee Spec under the new system.
> 
> IMPLEMENTATION PHASE IN
> =======================
> The Process Committee is going to recommend that non-standards track  
> be added "immediately", where "immediately" means something like the  
> beginning of the month following Board approval.  Changes to 
> currently  
> "in flight" standards track documents will be phased in so that work  
> product that is currently "close" to being approved will be 
> subject to  
> the old rules. The exact definition of "close" contained in 
> the first  
> para of Section 3.4 are still somewhat tentative. (I think it 
> is safe  
> to say they would only be loosened, not tightened.)
> 
> MORE MINOR CHANGES
> ==================
> 
> 1. Uniform 7 day membership deadline for initial TC meeting whether  
> f2f or telecon. (2.3)
> 
> 2. Clarified requirements for comment processing and made clear that  
> once a doc is out for public review if someone discovers a major  
> "oops" that requires a change before the review period ends, then it  
> must be withdrawn and resubmitted for a new public review (if the TC  
> so desires). (3.2 2nd and 3rd para)
> 
> 3. Clarified requirements around which versions of oasis 
> templates to  
> use. (3.4.1)
> 
> 4 Clarified rules around the mechanics of OASIS standard 
> ballots(3.4.3)
> 
> 5. Various other more minor clarifications, editorial changes, etc.,  
> some of which i've probably missed in the above list.
> 
>