OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

chairs message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary


I'm not aware of any requests to approve "things" that are not specifications, thus I question these chnages

-----Original Message-----
From: Jeff Mischkinsky [mailto:jeff.mischkinsky@oracle.com] 
Sent: Friday, January 08, 2010 11:07 AM
To: Anthony Nadalin
Cc: chairs@lists.oasis-open.org
Subject: Re: [chairs] Draft Jan 2009 TC Process changes summary


On Jan 08, 2010, at 10:36 AM, Anthony Nadalin wrote:

> Before I comment on these changes, I would like to have the rationale 
> for each of these changes to better understand them.

I tried to describe the motivations in the explanatory text.

Mostly, there has been a lot demand/request to add a way so that TCs can approve "things" that are not specifications.

>
> -----Original Message-----
> From: Jeff Mischkinsky [mailto:jeff.mischkinsky@oracle.com]
> Sent: Thursday, January 07, 2010 7: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.
>

--
Jeff Mischkinsky			          		jeff.mischkinsky@oracle.com
Director, Oracle Fusion Middleware 				+1(650)506-1975
	and Web Services Standards           			500 Oracle Parkway, M/S 2OP9
Oracle								Redwood Shores, CA 94065











[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]