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