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


The SDD TC, for one, made such a request, regarding documents such as Jeff 
notes in his original e-mail (including primer, profile, examples, best 
practices).

Regards,
Brent

Brent A. Miller
Senior Technical Staff Member, Master Inventor
Chief Architect, Tivoli Autonomic Computing & Component Technologies
IBM Corp.
Tel. 919-224-1027 (TIE 687)

"In theory, there is no difference between theory and practice. But, in 
practice, there is." 
-- Jan L.A. van de Snepscheut



From:
Anthony Nadalin <tonynad@microsoft.com>
To:
Jeff Mischkinsky <jeff.mischkinsky@oracle.com>
Cc:
"chairs@lists.oasis-open.org" <chairs@lists.oasis-open.org>
Date:
01/08/2010 02:52 PM
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]