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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tcproc-member-review message

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


Subject: TC Process revisions, comments


     I have recently acquired increased responsibility for the execution of 
this policy.  So I am turning to a careful examination later in this review 
than I would prefer.  There are a number of strong improvements in the 
revision.  Nevertheless, there are some specific items about which I have 
questions and doubts.
     A.  USER-FRIENDLY.  That goal is worth pursuing, if we expect 
membership growth among sectors who do not regularly participate as 
standards experts.   Reformatting, where that would make the document more 
approachable, should not be ruled out.  Among other things, all definitions 
should be intuitive;  and the "definitions" section probably should be 
moved to the rear -- so that what first confronts the new reader is rules 
(as they expect), not a long and abstract definitions section.
     B.  TC FORMATION - NAME.  The proposed rule that "all acronyms and 
abbreviations" must be included in the NAME of the TC seems 
unworkable.  For one thing this needs to refer only to acronyms for the 
COMMITTEE (e.g., "SSTC");  it is not always possible for a TC to foresee 
all acronyms that will apply to its SPECIFICATIONS, at design time.   For 
another, including them in the NAME is clunky and unnecessary.  (E.g., 
under this rule, would we have required one of our current TCs to name 
itself the "Web Services Security WS-Security WSS WS-S Technical 
Committee"?  Or even the "Web Services Security (WSS) TC"?  Ridiculous, and 
semantically unnecessary.)   To serve that goal, it would be sufficient to 
require that any acronyms for the TC name appear in the CHARTER, not 
necessarily in the TC NAME.
     C.  TC FORMATION - SCOPE/DURATION.   A variety of requirements in the 
charter, relating to deliverables and endpoints, treat TCs as if each is a 
tenuous project to be folded as soon as complete.  It may be the case that 
some TC projects should end immediately upon completion -- but there may be 
others which for legitimate reasons should continue long-term.  OASIS 
should provide a feasible home for both types.  A TC's duration is a 
decision best made in the negotiations that result in a charter's 
finalization.  It is inappropriate for OASIS to demand that all TC 
projects, of whatever type, sunset even if they continue to be active and 
productive within their topical scope.  Our rules need to look, and be, 
hospitable rather than hostile to standardization.
     A mandatory sunset-bias gives an advantage to, and invites, the 
proprietary recapture of standardized work.  Any TC can CHOOSE to give 
itself a limited life.   However, mandating that ALL TCs do so will result 
in OASIS losing TCs and projects.  That approach is unnecessary to protect 
members -- because parties who do not wish to be bound by a long-playing TC 
obligation can elect to remain outside of it, or withdraw.   Members who 
WANT a project to die at a specific point should bargain for this, in the 
charter at design time, not have it guaranteed as a default.
     A sunset-bias also works against OASIS' interests in the utility of 
TCs as a membership driver for OASIS.  Essentially it wastes an OASIS asset 
-- the project we host, its work product, and the good will built up around 
it.
     D.  TC FORMATION - DELIVERABLES.   The precise language constraining 
deliverables should not thwart a project which plans to create one 
specification, but discovers over time that it will need to create 
two.  (WSDM TC comes to mind.)  Nor should it be read to *imply* a bar on 
the creation of a v2., if the stated plan is to create a v1.0.    Lines 
452-454 of the review draft -- which contain a bias against permitting 
"v2"s, even when the charter expresses no preference -- should be 
deleted.   These rules will serve OASIS badly if they create the 
impression, or reality, of participants who thrust their hand into the fire 
to cooperate, but are anxious to pull it out (and override it with 
non-standardized extensions) as soon as humanly possible.  (As a strategy 
for an individual member, that's just fine.  As an institutional bias, it's 
not.)
     E.   TC FORMATION - MODE.  Should the three modes in the current IPR 
policy be *listed* in the TC Process, or just cross-referenced?   Listing 
them by name would render the TC Process obsolete as soon as the modes, or 
even their names, change.
     F.   WHITE PAPERS, etc.   The document continues not to be entirely 
clear about the handling of TC work product other than a 
"specification".  For example, it is hard to tell under the current 
definition of "Specification Ballot" whether votes to approve a non-spec 
white paper (which is, after all, a "document") would count against a 
voting member's 2-out-of-every-3 attendance obligation.
     G.   TC CHAIRS.  The application of a "Super Majority" vote to the 
removal of a chair seems to suggest that 25%+1 of the voting members of a 
TC (e.g., 6 of 20) can block a chair from being removed, even though 75%-1 
of the members (e.g., 14 of 20) wish it.  This seems to repose far more 
power in the chairs, and less in the TC members, than members might expect, 
and might immunize an unfair chair from fear of consequences, in the rare 
case where a chair and a small group might try to lead a TC in a direction 
that most of its members do not wish to go.  This rule seems much more 
authoritarian than other comparable rule-sets.  A lower threshold is more 
appropriate.
     H.  TC ADMINISTRATOR.  This defined term has changed;  however, the 
role is now a staff function, appointed and supervised by OASIS 
management.   Lines 48-49 and perhaps 835-837 should reflect this.   I 
believe the right outcome is that the 'TC Admin' role is subject to 
supervision ultimately by the CEO -- so that, for example, in an appeal 
under lines 856-874, the Board would have the right to expect that the CEO 
is entitled to be consulted in that first-level appeal (and thus can hold 
the CEO responsible for that outcome).  That seems necessarily to inhere in 
the powers that a CEO holds.  Otherwise, we would have the odd result that 
a TC rule dispute goes straight from a TC chair, to some OASIS middle 
manager, to the Board of Directors.
     I.  ELECTRONIC VOTING.  The wording at lines 514-520 is not entirely 
clear about the distinctions between web-based balloting and voting 
conducted on OASIS electronic mail lists.
     J. QUALITY.  I am concerned whether sufficient attention has been 
given to (a) an apparent PDF requirement -- suitable for all 
cases?  Appropriatelot defined as a nonproprietary format?  -- and (b) the 
characterization of a requirement for certain artifacts -- which might 
include .xsd schema, UML content, etc. -- as "plain text".
     K.  POST-MEMBER-BALLOT PROCESSING.  In lines 806-817 a TC is asked to 
choose one of three options, if a member ballot on a candidate OASIS 
Standard results in a small number of negative member votes.  The new 
proposed rule requires this choice to be made by "supermajority", so, 
unlike the prior rule, a majority of ~1/4 can block anything.  What happens 
if in 30 days the TC can not approve *any* of the three options by this 
extraordinary majority?  I do not see the argument for the extra obstacle, 
and thought that a simple majority requirement (as today) for options A 
(approve anyway) or B (withdraw) was sufficient.

Regards  Jamie Clark, OASIS







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