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

 


Help: OASIS Mailing Lists Help | MarkMail Help

oasis-board-comment message

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


Subject: RE: [oasis-board-comment] [OASIS-Appeal-001] Decision


Why is the Board spending time upon this before an appeal is before it? Shouldn't we respect due process?

Regards, Dave Ings,
Emerging Software Standards
Email: ings@ca.ibm.com
Yahoo Messenger: dave_ings


Inactive hide details for Peter F Brown ---2013-06-03 08:44:23 PM---Mike, On one point, I think you slightly misread Chet's brePeter F Brown ---2013-06-03 08:44:23 PM---Mike, On one point, I think you slightly misread Chet's breakdown: the sentence you refer to ("The d

From: Peter F Brown <peter@peterfbrown.com>
To: Michael DeNicola <MDeNicola@us.fujitsu.com>, Chet Ensign <chet.ensign@oasis-open.org>, Martin Chapman <martin.chapman@oracle.com>, Patrick Durusau <patrick@durusau.net>, Jacques Durand <JDurand@us.fujitsu.com>, "Paul C (Paul.Lipton@ca.com) Lipton" <paul.lipton@ca.com>, "smoser@de.ibm.com" <smoser@de.ibm.com>,
Cc: "tc-administration@lists.oasis-open.org" <tc-administration@lists.oasis-open.org>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>, "oasis-board-comment@lists.oasis-open.org" <oasis-board-comment@lists.oasis-open.org>
Date: 2013-06-03 08:44 PM
Subject: RE: [oasis-board-comment] [OASIS-Appeal-001] Decision





Mike,
On one point, I think you slightly misread Chet's breakdown: the sentence you refer to ("The definition of concrete cloud services, i.e. the definition of concrete component types, relationship types, and topology templates.") is the stuff that is *out* of scope. That is not changing.

There are a couple of minor, academic, points:
- The following sentence ("However, standardization of a basic set...") indicates what could be *in* scope and *that* sentence has been qualified (with the insertion of "non-vendor specific") - a qualification that, by being more specific, effectively limits the scope of that phrase.
- That sentence also originally included the phrase about "could begin in parallel....". It says "could", not "must" or "has to": Deleting a phrase that "x could do y" does not alter the scope, as far as I can tell.
I would argue that these points are academic and not relevant to the appeal.

However...
For me, the key phrase is "...standardization...is intended to be enabled by this work...".
Does that imply that such standardization cannot be part of "this work" (i.e. the current accepted and scoped work)? If something is "enabled to be done" does it mean that "the doing of it" necessarily and intentionally is *not* part of the current work?
That can be implied, particularly with the phrase "and could begin in parallel..." - such an interpretation could be grounds for accepting the appeal.

Frankly, the charter authors have done themselves no favors here and putting this sort of phrase in a formal charter is inevitably going to be a focus for anyone looking to pick it apart. At best, it's harmless; at worst, it leads to ambiguity. These "fluffy words" are not core to the definition of what is and what is not in scope and the charter authors may be regretting this.

On the other hand, the TC process document itself is equally badly worded in places, peppered with pseudo-precision, including the provisions regarding TC charters and clarifications. I fear that an appeal is being grounded solely on an ambiguous technicality: "You can't do x because you state that doing x 'is intended to be enabled by this work' and therefore is clearly not part of the work to be done." - it is not clear at all and it seems a very feeble ground for appeal.

My conclusions:
"Fluffy words" ("...is intended to be enabled by this work, and could begin in parallel with this project, with appropriate coordination") that are not core to the definition of what is in or out of scope cannot stand up as the *sole* basis of an appeal without any other substantiating grounds. Therefore, I would vote to deny the appeal.

regards,
Peter


-----Original Message-----
From: Michael DeNicola [
mailto:MDeNicola@us.fujitsu.com]
Sent: Monday, 03 June, 2013 15:34
To: Chet Ensign; Martin Chapman; Patrick Durusau; Jacques Durand; Paul C (Paul.Lipton@ca.com) Lipton; smoser@de.ibm.com
Cc: tc-administration@lists.oasis-open.org; tosca@lists.oasis-open.org; oasis-board-comment@lists.oasis-open.org
Subject: RE: [oasis-board-comment] [OASIS-Appeal-001] Decision

Chet,

I was not one of the people who appealed this matter to you; however, I'm afraid that I do not agree with your conclusion.

The original scope said:
"The definition of concrete cloud services, i.e. the definition of concrete component types, relationship types, and topology templates.
However, standardization of a basic set of concrete component types, relationship types and properties is intended to be enabled by this work, and could begin in parallel with this project, with appropriate coordination."

Here is how I read this:

The first sentence says the TC is chartered to do, "The DEFINITION [only] of concrete cloud services, i.e. [only] the DEFINITION of concrete component types, relationship types, and topology templates."

And the second sentence to say, "STANDARDIZATION of a basic set of concrete component types, relationship types and properties is intended to be ENABLED [but not done] by this work, and COULD begin IN PARALLEL WITH [but was not part of] this project, with appropriate COORDINATION [between the two efforts, i.e., TCs]." Why would it say "appropriate coordination" if there weren't two groups? A TC doesn't have to be told to "coordinate" work within itself.

It is clear to me that the TC was only chartered to DEFINE concrete component types, relationship types, and topology templates that would become the BASIS for development of STANDARDS for a basic set of concrete component types, relationship types and properties by ANOTHER GROUP. It acknowledges that the STANDARDIZATION work did not have to wait for the DEEFINITION work to be completed before it began, but that the TWO GROUPS had to COORDINATE their efforts.

I ask that you reconsider your decision. If not, I encourage the originators of this appeal to take it to the Board of Directors --- of which I am member.

Mike

Mike DeNicola

Fujitsu America, Inc.
1250 East Arques Avenue
Sunnyvale, CA  94085

Mobile:    (408) 829-9958
E-mail:    mdenicola@us.fujitsu.com
Web:      
http://us.fujitsu.com/solutions

This e-mail and any attached files are only for the use of its intended recipient(s). Its contents are confidential and may be privileged. Fujitsu does not guarantee that this e-mail has not been intercepted and amended or that it is virus free. If you have received this e-mail and are not the intended recipient, please contact the sender by e-mail and destroy all copies of this e-mail and any attachments.

-----Original Message-----
From: Chet Ensign [
mailto:chet.ensign@oasis-open.org]
Sent: Monday, June 03, 2013 3:27 PM
To: Martin Chapman; Patrick Durusau; Jacques Durand; Paul C (Paul.Lipton@ca.com) Lipton; smoser@de.ibm.com
Cc: tc-administration@lists.oasis-open.org; tosca@lists.oasis-open.org; oasis-board-comment@lists.oasis-open.org
Subject: [oasis-board-comment] [OASIS-Appeal-001] Decision

Summary:

On 09 April 2013, the TOSCA TC approved a Special Majority Vote to clarify its charter. On 01 May 2013, I announced the clarified charter to the membership of OASIS. On 16 May 2013, OASIS members Martin Chapman, Patrick Durusau and Jacques Durand submitted a written appeal to TC Administration stating their belief that the changes to the TOSCA charter expand the charter's scope and requesting that I invalidate the vote approving the clarification and require the TC to instead make the change by rechartering [1]. The detailed facts are laid out in an email to the parties involved and to the tc-administration@lists.oasis-open.org mailing list on 30 May 2013 [2].

After considering the issues raised in the appeal, the changes to the charter approved by the TC and the definition of charter clarification in the OASIS TC Process, I am satisfied that the changes approved by the TOSCA TC fall within the meaning of charter clarification and that the TC does not need to recharter. The appeal is denied.

Details of my decision are below. After the discussion, steps are provided for appealing this decision should any party wish to do so.


1. Details of this decision

1.a The appeal

The appeal raised two issues with the changes made to the charter:

a) "the new charter places an item within the scope of the TC which the original charter had explicitly declared as out of scope, thus widening not narrowing the scope of the TC."

b) "The original charter specified that work on standardizing concrete component types, whether vendor specific or not, would be done in other, yet to be chartered, Technical Committees. Changing this and bringing this work into the TOSCA TC widens the scope of the original TC."  

I agree with the appellants that if either of these assertions is true, then the TC did indeed expand its scope and thus could not approve the changes as a charter clarification. To determine whether they are true, we first review the changes made to the charter.


1.b Changes made to the charter

In its Special Majority Vote, the TC voted on changes contained in a red-lined version of the charter that was linked from the ballot [3]. Those specifically relevant to the appeal are:  

a) Item 1. listed in the "Out of Scope" section was changed from:

"1. The definition of concrete cloud services, i.e. the definition of concrete component types, relationship types, and topology templates.
However, standardization of a basic set of concrete component types, relationship types and properties is intended to be enabled by this work, and could begin in parallel with this project, with appropriate coordination."

to (with <insert>s and <delete>s flagged)

"1. The definition of concrete cloud services, i.e. the definition of concrete component types, relationship types, and topology templates.
However, standardization of a basic set of <insert>non-vendor specific</> concrete component types, relationship types and properties<insert>, which includes all attributes of the type and all contained elements, </> is intended to be enabled by this work <delete>, and could begin in parallel with this project, with appropriate coordination</>.

b) A new item 3. was added to the list of items "specifically in scope":

"3. Standardization of a basic set of non-vendor specific, concrete component types, relationship types and properties, which includes all attributes of the type and all contained elements."


1.c The meaning of clarifying a charter

Charter clarification is discussed in section 2.11 of the OASIS TC Process [4]. It begins by stating:

"A TC may clarify its Charter only for the purpose of removing ambiguity or for narrowing the scope of the topic defined by the Charter. The TC may not broaden or otherwise change its scope of the topic of work."

The crucial question in this situation is: "Did the changes made broaden the TOSCA charter; that is, did they make it possible for the TC to undertake work that it could not do under the original charter?"  

The first item listed as of out of scope in the original charter was "The definition of concrete cloud services, i.e. the definition of concrete component types, relationship types, and topology templates."

That item was then immediately qualified with a second sentence that read "However, standardization of a basic set of concrete component types, relationship types and properties is intended to be enabled by this work.".

The second sentence clearly limited the extent of the work deemed out of scope. It retained for the TC the right to produce *basic* concrete component types -- whatever that may mean in practice -- under the charter. We can all agree that this could have been written much better than it was. However, the effect of the sentence is quite clear: *basic* component types were always within scope.  

Did the addition of the words "non-vendor specific" and "which includes all attributes of the type and all contained elements" to the second sentence expand the scope of the work it permitted? I take them instead to be an effort to better explain what is meant by a *basic* component type - as efforts to limit the extent of what the limiting sentence itself allows. They do not have the effect of expanding the scope.

Did the addition of the new item to the in-scope list expand the charter? Given that the words it are identical to the words used in the "However" sentence, it cannot. It simply addresses the ambiguity caused by having in-scope work embedded in the out-of-scope section of the document. Once again, we can all agree that the original language could have been better, but this does not change the overall meaning of scope of the charter.

Lastly, did the deletion of the words "and could begin in parallel with this project, with appropriate coordination" from the end of the first out-of-scope item change the scope? The appeallants assert that these words meant that the work on basic component types would be done "in other, yet to be chartered, Technical Committees." I think this is a stretch. The sentence does not specify in any way where the work might be done and does not use the words "other Technical Committee" or anything like it. A more straightforward reading of that clause is that it allowed the TOSCA TC to start the work on basic component types in parallel with work on the specification itself "with appropriate coordination."

In conclusion, I find that the original charter enabled the TC to work on "basic component types" because of the language limiting the extent of the first out-of-scope item. I find that the additional words inserted into that sentence simply attempt to better describe what is meant by the word "basic." I find that the repetition of that second sentence in the in-scope section of the charter simply addresses the ambiguity of placement in the original charter. Lastly, I find that the words ". and could begin in parallel with this project." does not indicate that another TC was anticipated but rather was a procedural note on when work on a basic type could start.

I find that the TC has simply eliminated ambiguity from their charter. I affirm the clarification vote and the resulting charter clarification.

2. Procedure for appealing this decision

Appeal of this decision can be made by any party to the OASIS Board of Directors.

To appeal this decision, send the appeal to oasis-board-comment@lists.oasis-open.org and copy the TOSCA TC and tc-administration@lists.oasis-open.org. A copy of this decision is being mailing to the oasis-board-comment mailing list for reference.

Please reference [OASIS-Appeal-001] in the subject line to ensure continuity of the record across the respective mailing lists.  


--- References

[1] Email: "Appeal to the charter clarification recently made by the TOSCA TC," 16 May 2013:
https://lists.oasis-open.org/archives/tc-administration/201305/msg00000.html

[2] Email: "[OASIS-Appeal-001] Background and Facts for the Action Being Appealed," 30 May 2013:
https://lists.oasis-open.org/archives/tc-administration/201305/msg00024.html

[3] Red-lined version of the TOSCA charter approved by the TC:
https://www.oasis-open.org/committees/document.php?document_id=48749&wg_abbrev=tosca 

[4] TC Process, section 2.11 TC Charter Clarification:
https://www.oasis-open.org/policies-guidelines/tc-process


/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]