PAC: Suggested language for CS 6

[Jon Bosak <bosak@boethius.eng.sun.com>]

To: workprocess@lists.oasis-open.org
Subject: PAC: Suggested language for CS 6

In our discussion of CS 6, Language Communities, we were in the
end forced to deal with the question of how OASIS standards get
approved in the general case, because consideration of how we can
vote to approve a specification written in a language that most of
the members can't understand turns out to be an instance of the
more general problem of how we can vote to approve any
specification that most of the members can't understand.  For
example, OASIS as an organization would have basically the same
problem in voting to approve a specification for footwear written
in Japanese that it would have in voting to approve a
specification for the description of the human genome written in
English.

The approach we've decided on is to rely upon (a) an
administrative finding of compliance of a submission with a list
of formal criteria together with (b) the scrutiny of interested
parties to alert the membership to potential problems that should
prevent the submission from becoming a standard.  Note that this
strategy assumes the provision for public comment lists previously
adopted.

The language suggested below can fairly easily be extended to
include not just standards originating from OASIS TCs but also
from properly constituted outside groups.  I'm not sure whether to
make that extension now or to wait until we consider how we mean
to handle entry points into the process from outside.  Unless
someone objects, I intend to leave it this way and then amend the
language later when we specify the role of outside organizations.

Jon

==================================================================

CS 6. Standards and Languages

OASIS TCs shall be authorized to work in any language they choose.
The language of reference for a TC shall be declared at the same
time its meeting schedule is first proposed.  Formal actions of
TCs shall be governed by the same rules regardless of the language
in which the work is taking place.  Administrators designated by
the OASIS board shall be responsible for certifying compliance
with procedural and technical criteria.

A TC that has approved and published a committee specification may
simultaneously or at some later time recommend that the
specification be made an OASIS standard.  Upon resolution of the
TC to move the specification forward, its chair shall submit the
following items to a designated representative of the board:

   1. A formal specification that is a valid member of its type
      (if an XML schema, it validates; if source code for a
      program module, it compiles; etc.).

   2. Appropriate documentation for the specification, written in
      the language of reference.

   3. A clear English-language summary of the specification.

   4. Certification by the voting members of the TC that the
      specification is copyrightable and publishable by OASIS and
      usable by everyone without charge.  Standard language to
      accomplish this objective shall be prepared by OASIS counsel
      for use by all TCs.

   5. Certification by at least three OASIS member organizations
      that they are successfully using the specification.

   6. An account of votes and comments received in any earlier
      attempts to standardize substantially the same
      specification, together with the originating TC's response
      to each comment.

   7. A pointer to the publicly visible comments archive for the
      originating TC.

Thirty days shall be allowed for administrative processing of a
proposed standard.  The proposal shall be submitted to the OASIS
membership for a vote at the beginning of the calendar quarter
immediately following the 30 days allocated for administrative
review, and all votes shall be due at the end of that calendar
quarter.  The TC that originated the specification may, by formal
resolution, withdraw the proposed specification at any point
during the quarter in which voting is taking place on the
specification.

   [Note to friendly amenders: I believe that this is what we
   decided in discussion, but I am not sure that this is what we
   intended to decide.  I am troubled by the case where the
   proposal is submitted December 2, ends its administrative month
   January 2, is posted for a vote at the beginning of the next
   calendar quarter -- i.e., April 1 -- and finishes its vote June
   30.  Seven months minus a day is a long time.  Would it not be
   better to make every month a quarter boundary?  Then the
   passage would read:

      Thirty days shall be allowed for administrative processing
      of a proposed standard.  The proposal shall be submitted to
      the OASIS membership for a vote at the beginning of the
      calendar month immediately following the 30 days allocated
      for administrative review.  The voting period shall last
      three calendar months, with all votes due at the end of the
      third calendar month after submission of the proposal for a
      vote.  The TC that originated the specification may, by
      formal resolution, withdraw the proposed specification at
      any point during the three months in which voting is taking
      place on the specification.]

In votes upon proposed OASIS standards, every OASIS member
organization shall be entitled to cast one vote.  Individual
members (whether the membership is transferable or
non-transferable) shall not be entitled to vote in the approval of
OASIS standards.

   [Note that this is intended to reflect the current OASIS
   membership structure in line with our discussion.  Since the
   existing bylaws already distinguish between voting and
   nonvoting members, it would be logically equivalent to say
   nothing at all on this point, but silence will almost
   undoubtedly be misunderstood.  It would be clearer to say that
   the voting members for purposes of this section are the voting
   members in elections of the board of directors; this would be
   very clean with regard to future changes to the membership
   structure, but it would also allow this criterion to change if
   (for example) some future revision of the membership structure
   were to give individual members the right to vote in board
   elections.  Here I have assumed that we consider a vote by
   organizations rather than individuals to be fundamental to the
   difference between the approval of a committee specification
   and the approval of an OASIS standard.  Care will have to be
   taken in drafting language for the revised bylaws to correctly
   capture our intent.]

The results of a vote on a proposed standard shall be provided to
the membership and to the TC no later than one week following the
close of the voting period.

If a proposed specification has received no negative votes by the
end of the voting period, it shall become an OASIS standard.

If a proposed specification has received negative votes amounting
to 10 percent or more of the voting membership of OASIS, it shall
not become an OASIS standard.  This shall not prevent the same or
similar specification from being submitted again for a vote of the
membership.

   [Question: do we want to build in a delay here to prevent TCs
   from banging on the membership every four months until they
   find a window of approval or inattention?  One is tempted to
   say that the presidential candidacy of Harold Stassen over a
   period of something like 50 years never hurt anything, but the
   process we're describing here is not an approval process, the
   intertia of which would prevent any danger, but a disapproval
   process in which fatigue could very easily allow the passage of
   a bad specification if its proponents were persistent enough.]

If a proposed specification has received negative votes totaling
less than 10 percent of the voting membership of OASIS, the
negative votes and accompanying comments, if any, shall be
forwarded to the originating TC for consideration.  After
notification of the results, the TC shall have 30 days to take one
of the following actions with regard to a submission that has
received negative votes from less than 10 percent of the
membership:

  (a) The TC may withdraw the submission.

  (b) The TC may resubmit an amended specification; in this case,
      the amended submission shall be considered as if it were a
      new submission, except that information regarding previous
      votes and the disposition of comments received in previous
      votes shall accompany the amended submission.

  (c) The TC may accept the submitted specification unchanged; in
      this case it shall become an OASIS standard 30 days after
      notification of the results.  This is the default outcome if
      the TC takes no action within 30 days following notification
      of the results.