Re: OASIS member review of proposed revision of TC Process

[jon.bosak@sun.com]

Following are my comments on the proposed revision of the OASIS TC
process.

Jon

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Comments on the document "TC Process Revisions, September 2003 to
October 2004"
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

| A TC Member may request voting privileges by making a request
| using the electronic collaborative tools (i.e. Kavi database);
| a probationary period follows the request. At the end of the
| probationary period, during which the Member must attend two
| out of three meetings, the Member gains voting rights.

What constitutes "a meeting" for purposes of this process?

If a TC meets for five consecutive days, is that one meeting or
five meetings?

 - If it's one meeting, does appearance on any of the five days
   count as attending the meeting?

 - If it's five meetings, does missing two days out of the middle
   put the member in violation of the attendance requirements?

In either case, does a member have to call in during plenary
sessions to count as attending, or do call-ins during breakout
sessions count as well?

| Voting rights must be maintained by regular attendance and
| returning electronic ballots; attending one meeting and
| returning one electronic ballot are equivalent, and the Member
| must maintain a record of two out of three to maintain voting
| rights.

This is confused, and so is the corresponding section of the new
process itself.

This part of the original process (which was copied more or less
verbatim from ANSI, a fact that should immediately make you
hesitant to change it without thinking it through) was consonant
with the first independent clause above, that is, it required
regular attendance AND regular votes.  But the rest of this
description suggests that a member can maintain good standing by
attending meetings OR casting votes.  I'm not opposed to loosening
the requirements a bit, but if that's the intent, the new version
is seriously underspecified.

Consider the following sequence of events:

   1. TC meeting
   2. Ballot 
   3. TC meeting
   4. Ballot
   5. TC meeting
   6. Ballot

 - A member attends all three meetings (1, 3, 5) but does not vote
   (2, 4, 6).  Does he remain in good standing at the end?  (The
   old process would say no, but the new one appears to say yes,
   because meetings and ballots are equivalent.)

 - After consistently attending all meetings and responding to all
   ballots, a member attends 1 and votes 2, but misses 3 and 4.
   Still in good standing at 5?  (The old process would say yes,
   but the new one says no.)

By keeping meetings and ballots distinct, the old process required
members in good standing to keep up with both.  By making meetings
and ballots equivalent, the new process makes good standing
arbitrarily dependent on the order in which ballots and meetings
happen to occur; a member who attends all meetings but does not
vote may or may not be in good standing depending on the way that
meetings and ballots are interleaved, and similarly for a member
who responds to all ballots but does not attend any meetings.

This part of the process wasn't broken and should have been left
alone.  The part that needed fixing was the definition of meeting
attendance, which this revision has still not addressed.

| (An effect of the above is that a person who is a Member of a
| TC may become a member of the TC's subcommittee (SC) without
| being an active participant in the TC; i.e. the person may be
| active in the SC without being active in the parent TC.)

Excellent!  I can't wait for this part to become operational.
Note that one side effect is that it's no longer necessary to
loosen the requirements for good standing in the TC (which I'm
guessing was the intent of the conflation of meetings and ballots
commented upon above).

| All resources of the TC and its associated subcommittees,
| including web pages, documents, email lists and any other
| discussions, must be located only on facilities provided by
| OASIS; TCs and SCs may not conduct business or technical
| discussions, store documents, or host web pages on non-OASIS
| servers.

If OASIS provided usable facilities for things like modifiable
files at persistent locations, this policy would merely be
unenforceable, but given the complete lack of such facilities,
it's simply absurd.  In particular, the injunction against copying
documents to non-OASIS facilities directly contradicts the OASIS
copyright, which says that users can freely copy and distribute
such materials.  And of course any TC members who try to work on a
document using their own computers have broken this rule by
locating that document on facilities not provided by OASIS.

| All web pages, documents, and email archives of all TCs and SCs
| shall be publicly visible.

Extend this visibility policy to materials located outside of the
OASIS site and you have accomplished everything useful in this
area.  All that's left is an obsessive territoriality that seeks
to maintain illusory control at the cost of real functionality.

| Comments made to the TC from anyone other than a TC Member must
| be made via the TC's web comment form. (This is required by the
| new OASIS IPR Policy which requires that a Feedback License be
| attached to all comments received; i.e. all input to the TC must
| be covered wither by the Membership Agreement, which covers
| members of the TC, or the Feedback License, which covers
| everyone else.)

"Wither"?  Meaning "whether"?

| TC meetings must be properly called and scheduled in advance
| using the OASIS electronic collaborative tools.

Requiring a pull technology for announcements is a bad idea,
especially given people (like me) who can check email more often
than they can access the web.  This is like saying that people
must be served with a legal notice by registered mail but
requiring that they go down to the post office every day to find
out whether anyone might be interested in sending them such a
message.  It looks to me like another example of the obsessive
desire for control taking precedence over functionality.

| Meeting minutes must be recorded and published to the
| TC's email list and referenced on the TC web page.

I'm glad to see push technology being used sensibly for publishing
minutes, but the requirement to reference each set of minutes
right on the TC web page is going to make for some pretty
sad-looking web pages after a while.  

By the way, any requirement to publish a reference to something in
an email archive adds a large overhead to day-to-day operations
because Kavi does not provide email URLs in the message header;
instead you have to come back later to find out what URL got
assigned, and only then can you create a link.

| Super Majority ballots must be conducted by the TC Admin in
| order to ensure proper process and notification.

Any functional reason for this, or is it just another example of
control for the sake of control?  The process and notification are
enforced by kavi, right?

| Any TC Member may make or second a motion, but only Members with
| voting rights may vote.

Giving members who can't even vote the right to tie a meeting into
knots evidences a remarkable lack of understanding about how
parliamentary processes are supposed to work.  Under this
provision, a TC could be kept continuously occupied with the
formal consideration of resolutions that did not have the support
of a single voting member!

The original TC process left most of the procedural details to
Robert's for a reason: after a couple of hundred years of testing,
the difficult cases have already been discovered and worked out.
Unless there is an overriding reason to address some requirement
specific to OASIS TCs, attempts to tweak Robert's are almost
always ill advised.  If the intent here was to allow nonvoting
members to make suggestions, that's already covered by allowing
them to speak in meetings and post on mail lists.  If a suggestion
can't find even one voting member to propose it, it shouldn't be
brought up for formal consideration.

(I find further on, to my relief, that this provision is directly
contradicted by lines 502-503 of the proposed new process document
itself.)

| Editable (source) versions of all files must be submitted to
| the TC's document repository.  All TC-approved documents
| (i.e. anything the TC votes to approve) must also have HTML and
| PDF versions submitted to the doc repository.

How is it proposed to deal with differences in line numbering and
pagination between these different formats?

If the intent here is to make the editable form canonical,
shouldn't the process rule out proprietary formats such as Word?
The only international standards mentioned in this paragraph are
HTML and PDF.

It would be interesting to know what this provision is actually
intended to accomplish.

| Any changes made after approval, except for the change in status
| information, must be re-approved.

If the intent here is to prevent multiple versions of a
specification, it directly contradicts what appears to be the
intent of the requirement stated above to submit everything in
editable form.

| A Committee Draft can be sent to public review and is known at
| that point as a Pubic Review Draft.

Because this is where we expose our work to nit-pickers?

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Comments on the document "OASIS OPEN Technical Committee Process"
dated 7 October 2004
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

| “Subcommittee” (“SC”) is a group of Technical
| Committee Members producing recommendations for consideration by
| the parent TC.

As written, this definition equally well describes ad hoc work
teams.  I think we need a more precise wording, for example,

   "Subcommittee" ("SC") is a formally constituted group of
   Technical Committee Members that has its own web page and
   archived mail list and is chartered to produce recommendations
   for consideration by the parent TC.

| "Super Majority Vote" is a vote in which at least 2/3 (two
| thirds) of the TC Voting Members vote "yes" and no more than
| 1/4 (one fourth) of the TC Voting Members vote "no". These
| numbers are based on the total number of Voting Members on the
| TC's roster, regardless of the number of Voting Members present
| in the meeting.  Abstentions are not counted. For example, in a
| TC in which there are 20 Voting Members on the TC's roster, at
| least 14 Voting Members must vote "yes" for a motion to pass,
| but if 6 or more vote "no" then the motion fails. All Super
| Majority Votes must be conducted by the OASIS TC Administrator.

My thus far unsatisfied curiosity regarding the reasons why a 2/3
vote has to be conducted by the Administrator (while a simple
majority or absolute majority vote does not) is here overshadowed
by the vision of the Administrator being flown out to the TC
meeting to conduct the vote.  The nonvoting members noted above
may find it amusing to propose resolutions requiring a Super
Majority Vote just to see the Administrator fly halfway around the
world every day in order to conduct votes on questions that no
voting member of the TC is interested in considering.

Since it appears from this provision that the Administrator may
have to attend every meeting of every TC in order to be present in
case a vote requiring a Super Majority is called, perhaps we
should consider deputizing every TC chair to act as Administrator
under these circumstances.

| The proposed TC name is subject to TC Administrator approval
| and may not include any misleading or inappropriate names. The
| proposed name must include any acronyms or abbreviations that
| will be used by the TC.

In the UBL TC we use the abbreviations ABIE, ACC, ASBIE, ASCC,
BBIE, BCC, BIE, CC, EAN, EDI, ISO, NDR, UML, UN/CEFACT, XML, and
XSD.  (Actually, we use a lot more than that, but these are the
ones that are called out in our specification.)  I'm sure glad
that this rule wasn't in place when we started the UBL TC; if I'd
had to refer to it as the OASIS UBL ABIE ACC ASBIE ASCC BBIE BCC
BIE CC EAN EDI ISO NDR UML UN/CEFACT XML Technical Committee, I'd
probably have developed carpal tunnel syndrome by now.

| The scope of the work of the TC, which must be germane to the
| mission of OASIS, and which includes a definition of what is
| and what is not the work of the TC, and how it can be
| determined when the work of the TC has been completed.

Here's another provision that I'm glad we didn't have to comply
with.  If I had been required to enumerate everything that is not
the work of the UBL TC, I would still be working on the
submission.

| Such other contributions will be considered by the members of
| the TC on an equal basis to improve the original starting point
| contribution.

What does "on an equal basis" mean?  Does it mean that all
contributions will be given equal weight regardless of their
applicability or quality?  Isn't a TC supposed to be made of
experts who are qualified to judge some contributions to be better
than other contributions?

| Specification of the IPR Mode (RAND, RF-Restricted, or
| RF-Unrestricted), as defined by the OASIS IPR Policy, that the
| TC will operate under.

Since the IPR policy is explicitly called by reference in order to
decouple the process from future changes to the policy, I think it
would be best not to embed the parenthesized enumeration in the
process.

| Identification of similar or applicable work that is being done
| in other OASIS TCs or by other organizations, why there is a
| need for another effort in this area and how this proposed TC
| will be different, and what level of liaison will be pursued
| with these other organizations.

There are two things wrong with this:

1. The scope ("similar or applicable") is impossibly broad (what
   is not potentially "applicable"?), and

2. It is impossible for the members to know whether there is group
   somewhere else in the world that is doing similar work.

It follows that the language required by this provision would
constitute a statement about the members' knowledge
rather than a statement that usefully identified every possible
connection with other efforts.

The original TC process was based on the premise that in a
publicly open environment, the burden of identifying overlaps or
conflicts with work outside of OASIS would lie with the outside
groups or interests pursuing that work.  This was one aspect of
the basic design center of the whole process, which was to
maximize the work output of expert volunteers by reducing the
procedural and organizational overhead under which they were
required to labor.  The evolution of the process over the last few
years has been continuously in the direction of heaping more and
more procedural cruft on the people who are supposed to be doing
the work, including the OASIS staff, while the difference between
OASIS and older organizations continues to shrink along with its
reason for maintaining a separate existence.

| Persons intending to participate in the first meeting must
| register as a TC Member and specify whether they intend to gain
| voting rights, using the electronic collaborative tools
| provided by OASIS no later than 15 days prior to the event, and
| must be an Eligible Person at the time they register.

This paragraph suffers from several grammatical and structural
problems.  Here is a cleaner version:

   Eligible Persons intending to participate in the first meeting
   must use the OASIS collaborative tools to register as TC
   members, and to specify whether they intend to gain voting
   rights, no later than 15 days prior to the event.

Note that the definitions of "Eligible Person" and "Member" make
it unnecessary to repeat that only Eligible Persons are eligible
to be Members.

| At the first meeting the TC must elect a Chair as the first
| order of business. Once the Chair is elected the role of
| Convener ends.

More otiose overhead.  The point of naming a chair in the TC
proposal was the same as specifying a meeting schedule: so people
would know what kind of group they were signing up for.  The need
to identify the chairmanship of the TC is recognized in line 208
but then contradicted by this provision at lines 242-243 that
makes it impossible to guarantee that the chair will actually turn
out to be the one that was advertised when recruiting participants
for the TC.

| Upon receipt by the Chair of confirmation by the Primary
| Representative by the Chair the Member may begin participating,
| but will not have voting status.

The phrase "by the Chair" appears one too many times in that sentence.

| The TC Member will gain voting rights immediately after a
| probationary period, which starts when the Member requests
| voting rights via the electronic collaborative tools, and lasts
| until the close of the third meeting or 60 days following the
| request, whichever comes first.

Note comments above regarding the need to define "meeting" in this
context.  I don't have any good suggestions here, I'm just noting
that it's a serious problem.

| To maintain voting rights, a Member must attend two out of
| every three Meetings and/or vote in two out of every three
| Specification Ballots.

See previous comments regarding meetings vs. ballots.  The
"and/or" here is exactly the crux of the problem: is the
requirement "two out of three meetings OR ballots" or "two out of
three meetings AND ballots"?  And what kinds of ballots are we
talking about, anyway -- simple majority or absolute majority or
super majority?

| For the purpose of this requirement submitting one
| Specification Ballot is equivalent to attending one Meeting,
| except when ballots are open at the same time meetings occur;
| i.e. meetings and ballots occurring at the same time will count
| as a single event.

OK, so suppose a meeting and a ballot are held at the same time,
and I attend the meeting but don't vote.  Does that
count or not?

| A Member may relinquish his voting rights by sending a
| statement to that effect to the TC email list.

Suppose a member ignores this (either deliberately or through
ignorance) and sends a note to the chair instead of the mailing
list.  The chair tries to follow this provision by begging the
member to copy that note to the list, but to no avail.  According
to this, he remains a voting member even though he told the chair
that he didn't want to be.  This should say "by sending a
statement to that effect either to the chair or to the TC email
list."

| The responsibilities of Chair of a TC may be discharged by no
| more than two co-Chairs.  In the event that the Chair position
| is so shared each co-Chair is equally responsible for the Chair
| duties and responsibilities. Throughout this TC Process,
| whenever a notification to the TC Chair is required this must
| be made to both co-Chairs.

This completely ignores the question of what happens when the
co-chairs disagree about what to do next.

| A TC Chair may be removed by action of the Board of Directors
| or by a Super Majority Vote of the TC. In the event that a TC
| has co-Chairs each may be removed individually or both may be
| removed by a single action.

How does this actually work?  The members can't consider a
resolution unless it's been stated by the chair, and they can't
hold a meeting without the chair; are they supposed to petition
the Administrator, or what?

| A vacancy in chairing a TC shall be deemed to exist when (i)
| the Chair or one or both co- Chairs has been removed, (ii) the
| Chair or one or both co-Chairs has resigned the position, or
| (iii) the Chair or one or both co-Chairs ceases to be a member
| of the TC.  Vacancies in chairing a TC shall be filled by
| election from the membership of the TC.

The effect of this paragraph as written is to require any TC that
begins with two co-chairs and subsequently loses one of them to
forever have two co-chairs; it can never choose to leave one of
the positions empty.  Is this what was intended?

| All resources of the TC and its associated subcommittees,
| including web pages, documents, email lists and any other
| discussions, must be located only on facilities provided by
| OASIS; TCs and SCs may not conduct business or technical
| discussions, store documents, or host web pages on non-OASIS
| servers. All web pages, documents, and email archives of all
| TCs and SCs shall be publicly visible.

See comment on this above.

| Comments will be publicly archived, and will be forwarded to
| one or more TC members including the TC Chair.

How are these members chosen?  How is that choice implemented?  If
I'm not one of the members who gets to see the comments but want
to be, how do I go about requesting this?  Can my request be
denied?  If so, upon what grounds?  If not, why not just make the
distribution list (assumed to be read-only) the same as the TC
list?

| The TC must keep the following information current on the TC
| web page: the TC name and charter; standing rules and other
| adopted procedures; meeting schedule; anticipated deliverables
| and delivery dates; list of TC members; the name and email
| address of the TC Chair or co-Chairs as well as other positions
| such as secretary, editor, etc. that may exist; list of
| subcommittees, their deliverables, and members;

I can't believe that it's intended to literally put all of this
stuff on a single web page.  Shouldn't most of these be links to
the stated information?

| Every important change in TC status shall be posted to the
| announcement list, such changes shall include

That's a comma splice; replace with period or semicolon.

| but not be limited to the following: TC formation; TC charter
| revision; start of Public Review; approval of Committee
| Specifications; , submission of a Committee Specification as a
| proposed OASIS Standard;

Lose the comma before "submission."

| Standing rules may be adopted by Full Majority Vote of the
| TC. The TC may not adopt standing rules or other Resolutions
| related to IPR, quorum requirements, membership, voting,
| participation, or that otherwise conflict with or supercede

That's spelled "supersede."

| Standing rules must be communicated to the TC Administrator who

Comma required before "who."

| may override them if they are in conflict with OASIS policy,
| and must be published on the TC's web page.

I think we want to link them from the web page, not actually print
them there.

| Without a quorum present discussions may take place but no
| business may be conducted; those present may act as a
| “Committee of the Whole” as defined in Robert’s Rules
| of Order Newly Revised, and make a report to the entire
| TC. Attendance must be recorded in the meeting
| minutes. Meetings without quorum will still count towards
| attendance for purposes of Members gaining, maintaining, or
| losing voting rights.

I don't have RRNR with me as I write this, but the structure
described may not be strictly speaking a committee of the whole,
although I've been referring to it under that name.  It does look
a lot like one, but I seem to recall that strictly speaking a COTW
has to be formed on the spot by the genuine resolution of a
quorate body, which of course doesn't exist in this situation.  I
think what I've been meaning is that the standing rule (properly
adopted) authorizes the automatic creation of something that
operates exactly like a real committee of the whole would operate
if the TC were quorate and had decided to operate that way.
Someone should look into this and decide whether this is a COTW
that is cooked up in advance or whether it's a special ad hoc
committee that springs to life under such circumstances and
operates like a COTW.  Something like:

   Without a quorum, the voting TC members present at a previously
   scheduled and noticed meeting may operate according to the
   rules of a Committee of the Whole and report their preliminary
   recommendations to the whole TC via email together with
   proposals for their adoption.  Attendance at such an
   automatically constituted ad hoc committee shall be recorded in
   the meeting minutes and shall count towards TC meeting
   attendance for purposes of Members gaining, maintaining, or
   losing voting rights.

This isn't completely cooked yet, but you get the idea.  There's a
decision to be made here whether nonvoting members get to vote on
recommendations in such a situation; I think not, so that's the
way the paragraph above is written.

| TC Charter Clarification

Global comment on the whole section:

The word "clarification" was intended to convey the intention that
TCs could change the details of what they were doing but not the
basic commitment with which they initially attracted
participation, whatever that might be.  Since this idea is
described in more detail in the section as currently written, I
think it would be more straightforward to just substitute
"revision" for "clarification" (and "revise" for "clarity," etc.)
throughout.


| TC votes require a Simple Majority Vote to pass, except as
| noted elsewhere in this Process. All TC ballots requiring a
| Super Majority Vote for approval must be conducted by the TC
| Administrator; the TC Chair shall notify the TC Administrator
| that a motion has been made which requires a Super Majority
| Vote, and the TC Administrator shall set up and conduct the
| ballot.

I continue to think that a TC chair who can handle the fraction
1/2 can also generally be trusted to deal capably with 2/3 and 1/4
as well.

| TCs may conduct electronic ballots via the TC’s general mail
| list or the publicly archived electronic voting functionality
| provided by OASIS. The minimum period allowed for electronic
| voting shall be seven calendar days; the TC may specify a longer
| voting period for a particular ballot.

Experience has now shown that the original five days for a vote
works better than the present seven.  Seven makes it impossible to
propose and dispose of a question during one weekly meeting cycle,
effectively cutting in half the maximum speed at which a TC can
operate using a combination of phone and email.  Six days would
work; seven doesn't.

| A motion to open an electronic ballot must be made in a TC
| meeting unless the TC has adopted a standing rule to allow this
| motion to be made on the TC's email list. A TC may adopt a
| standing rule allowing for Members make motions via the TC's
| general mail list; seconding of the motion and discussion would
| also take place via the mail list, with voting via the mail
| list or the publicly archived electronic voting functionality
| provided by OASIS. In the absence of such a standing rule
| motions may only be made in a TC meeting.

Allowing motions to be made via email is a breathtakingly bad
idea.  It's hard to think of a more certain prescription for chaos
in the functioning of a TC.

I have actually spent some time, by no means all of it alone,
thinking through what would be required to make electronic
parliamentary procedure work electronically; let's just say that
it requires more than what kavi currently has to offer.  See
Governance: The Killer App? in Government Technology, November
2000 (http://metalab.unc.edu/bosak/pa/govtech.htm).

I can't really object to this passage, because it allows TCs run
by sensible people to steer clear of the edge, but I predict that
few TCs can work successfully if people actually try to operate
this way.  Setting aside the whole nightmare of keeping privileged
motions separate from main motions and subsidiary motions and so
on, the cycle of formal amendment that would be required to work
out a consensus would take far too long.  Much better to spend the
time in informal discussion and give the chairs the job of
proposing the motions, which should always come only after a
consensus or near-consensus has already been achieved, or in the
worst case a majority position established and not likely to
change.

| TC Coordination

What a shame that the "JC extends TC" structure of the original
process has been abandoned!  By simply specifying that a JC was a
special kind of TC, the old spec was both more compact and more
comprehensive.  It also avoided all the complications that
invariably attend a delegate structure, which the new process now
has to cope with but hasn't sufficiently dealt with yet.

Loss of elegance aside, there is one major thing here that has
changed and one major thing that is now underspecified.

The major change here is that JCs can be formed with one intention
and then manipulated to change their intention.  If TCs A, B, and
C form a JC, then that JC is by implication for the purpose of
coordinating A, B, and C.  Under the old process, a change to
include D required the formal approval of A, B, and C: "A TC shall
be added to or removed from the set of TCs contributing to a JC
only upon joint resolution of all of the participating TCs."
Under the new process, D (and E and F and G and all of their
friends and relatives) can just walk in and take over.  So if, for
example, A and B and C are working on a set of related
specifications that compete with the approach championed by a big
vendor working in D and E and F and G, then A and B and C can't
form a JC designed to help them work together more effectively
without the participation of members from D, E, F, and G dedicated
to interfering with that work.

The major underspecified thing in the new section is how the
delegates to the JC relate to both the JC itself and the TCs they
are representing.

In the old process, the fact that a JC is a kind of TC means that
the members participate as individuals under all the usual
individual requirements; with the addition of a few rules unique
to JCs, the relationship of members to the JC is all done.

Back home, the question of how representatives are appointed by,
report to, or are empowered by their TC is under the old process
completely specified by saying that the TC appoints a subcommittee
whose job it is to participate in the JC.  Then all the procedures
that apply to SCs apply to the team representing the TC, and again
we're done.  The new process doesn't really deal with all of this
in any detail to speak of.

To sum up, there are probably a lot of things that could be done
to improve JCs, but I'm not seeing any improvement in this
revision that would justify the fairly steep drop in concision and
coverage.

| Disclosures of patents required by the OASIS IPR Policy are
| made by sending an email message to the TC Administrator who
| will post the disclosure on the TC's web page

A comma is required before "who."  And I think that "with regard"
scans better than "in regards"

| A Contribution, which is defined in the OASIS IPR Policy, is
| made by sending to the TC's email list the contribution or a
| notice that the contribution has been submitted to the TC’s
| document repository; a URL or other reference to the document
| is not sufficient.

The first "TC's" uses an ASCII apostrophe, while the second one
uses the inverted comma code point; stuff like this should be
checked for using find/replace.

| Editable formats of all versions of TC documents must be
| submitted to the TC’s document repository.

So if I go through a dozen versions of a document that I'm working
on in the course of a couple of days of work, I have to submit
them all to the document repository when I'm done?  I can't
believe that this sentence is intended to be taken literally.  How
is "version" being defined here?  If you mean that all versions
important enough to be shared must be submitted to the TC's
document repository, I can support that, but if that's what's
intended then of course there is no need to say it.

| The TC may conduct any number of review cycles (i.e. approval
| to send a Committee Draft to Public Review, collecting
| comments, making edits to the specification, etc.). The first
| public review of a specification must take place for a minimum
| of 60 days, and any subsequent reviews must be held for a
| minimum of 15 days. Changes made to a specification after a
| review must be clearly identified in any subsequent review, and
| the subsequent review should be limited in scope to changes
| made in the previous review.

The last half of the last sentence is going to be unenforceable in
practice.  The discovery of major problems that have escaped
previous detection is a normal and necessary part of the process.

| The specification may not be considered for approval by the TC
| as a Committee Specification until there is a review cycle with
| no comments that result in Substantive Changes to the
| specification.

I would suggest:

   The specification may not be considered for approval by the TC
   as a Committee Specification until it has undergone a review
   cycle during which it has received no comments that result in
   Substantive Changes to the specification.

| Simultaneously with the approval of a Committee Specification
| or at a later date, a TC may resolve by Super Majority vote to
| submit the Committee Specification to the membership of OASIS
| for consideration as an OASIS Standard. Upon resolution of the
| TC to submit the specification, its Chair shall submit the
| following items to the TC Administrator:

The current process requires only a majority vote to submit a CS
for standardization.  Why is it now required to hold another great
big supermajority vote to forward to the Administrator something
that has already undergone a great big supermajority vote by the
same people?  Looks like just more red tape for the joy of red
tape to me.  If the idea is to exercise more control over the
standardization process, then that should be addressed directly,
not achieved simply by putting more procedural obstructions in the
way of the TCs to slow them down.

| If at the end of the voting period at least 15 percent of the
| voting membership has voted to approve the proposed standard,
| then if no votes have been cast to disapprove the proposed
| standard, it shall become an OASIS Standard immediately
| following the end of the voting period. However, if negative
| votes amounting to less than 15 percent of the voting
| membership have been cast, the TC will be notified of the
| negative votes, after which the TC shall have 30 days to take
| one of the following actions by Resolution of a Super Majority:

Same here.  Why require a super majority when the existing simple
majority works fine for this?  Even under the existing system, all
it takes is one no vote out of hundreds to seriously affect a
release schedule; now this puts a big procedural hurdle in the way
of progress right when half the TC has gone on vacation to recover
from finishing the spec and putting it up for standardization.
What an invitation to make trouble!

And has anyone considered the effect of adding all this rigmarole
to the job load of the Administrator?  The original process was
designed to reduce this load to the maximum extent possible; many
of the changes in the new version seem designed only to increase
it.

| The “OASIS TC Administrator,” as defined in Section 1 of
| this TC Process, will act as the Technical Committee
| (“TC”) Liaison to the Board for the purpose of keeping
| the Board apprised of activities related to the TC Process. The
| specific duties of the TC Liaison shall be specified by the
| Board in conjunction with the TC Administrator

I suspect that "consultation" was meant instead of "conjunction"
here.

| (The TC Administrator shall also send a copy of proposals for
| the creation of new TCs to the Technical Advisory Board (TAB)
| for their comment.)

The parens are out of place here.

One further global comment: The original process used "shall"
throughout to indicate necessity.  The new one mixes "shall" and
"will," usually with the same meaning, frequently in adjacent
sentences.  An editing pass should be performed to turn all of the
"wills" that mean "shall" into "shall."

Jon