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


Help: OASIS Mailing Lists Help | MarkMail Help

opencsa-ms message

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

Subject: Re: [opencsa-ms] Proposed Additions for next OpenCSA MS Steering Committee call

On Oct 08, 2010, at 12:56 PM, Mike Kaiser wrote:
   Thanks mike for getting this started.

    To start some discussion of these items earlier than the next  
call ...

> I would like to propose the following items be added to the next  
> Steering Committee agenda for discussion/resolution:
> 	• Review of status from each of the TC's for:
> 		• Specifications
> 		• Test Suites
> 		• Implementations anticipated to be used for compliancy testing
> 		• High level status of any compliancy testing which may have  
> already started.
> 		• TC estimated timeline for exit criteria to be met for CS  
> Approval which is ready for SC review.
> 		• Statement of intent (or lack of intent) on what is destined for  
> OASIS Standardization
> 	• Formal SC agreement from SC that TC's can achieve Committee  
> Specification state without having achieved all exit criteria  
> necessary to take CS to OASIS Standardization phase.

I don't understand this. By definition this is true. There are  
criteria for CS (defined by the TC Process generically plus what's  
required by a TC charter). Steering Committees have nothing to say  
about CS votes.

> 	• Formal SC agreement on criteria to be used for what is considered  
> an implementation suitable for compliancy testing in the eyes of the  
> SC approval when considering approval of a submitted package  
> proposal to go forward for OASIS Standardization.

I agree that we should have some discussions within the SC about what  
we would like to see. I don't know what you mean by "formal SC  
agreement". I will repeat (as many times as necessary :-), you cannot  
get a group to pre-commit to a future action. Regardless of what  
motions are passed as to intent to take an action in the future by a  
group, when the future arrives, there will be a motion put forth to  
take the contemplated action. The members of the group will then vote  
however they want on that motion, regardless of what happened in the  
To be concrete, lets assume the SC votes something along the lines of  
"it is the intent of the SC to approve the foo spec only when there  
are 5 implementations which pass the following 303 tests". At the next  
meeting an SC member could move to approve the "foo spec", even though  
there are only 2 implementation which pass only 3 of those 303 tests.  
If the requisite majority votes to approve, then the foo spec will be  
approved - even though the same people had voted to say they had a  
different intent the week before. "I changed my mind".

To summarize:
Having the discussion to see if folks are in general agreement, or to  
find out where the disagreements are, and to see if those  
disagreements can be resolved, is a very good thing. Trying to take  
that discussion to the next level to bind the group to a future action  
is not possible and leads to large amount of times wasted crafting  
exact wordings of a motion that is a no op.

> 	• Determination as to what minimal set of "packages" will be  
> required by the SC in order to allow any to proceed to OASIS  
> Standardization phase.

see above - see if we have have general agreement, individually, as to  
what we think the minimal set would be a good thing.


> 	• Resolution/Status of all open AI's
> Thanks,
> Mike
> IBM Emerging Internet Software Standards
> Phone: 919-254-7605  T/L 444-7605

Jeff Mischkinsky			          		jeff.mischkinsky@oracle.com
Sr. 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]