Message-Id: <9009251939.AA08919@expire.lcs.mit.edu>
To: vex@expo.lcs.mit.edu
Subject: What is this VEX list, anyway?
Date: Tue, 25 Sep 90 15:39:09 -0400
From: rws@expo.lcs.mit.edu (Bob Scheifler)

A number of you may be surprised that you are suddenly on a Consortium-private
mailing list.  I hope that's not the case, (and I hope you really are from a
Consortium organization, and that if you aren't you'll let me know...), but
in case you don't know how we operate, and are wondering about this
"Trial Review" and "Technical Review" stuff, here's a summary of the process
we go through:

The VEX proposal is being proposed by Tektronix as an official standard
of the X Consortium.  As such, it will undergo the review outlined below.
Todd Brunhoff is the Architect for the review.  This mailing list will be
used for the review.  You should provide input to your Advisory representative
as to how to vote at the various stages of the review.

(Note: "member" means "Member or Affiliate".)

		     Consortium Evaluation Process

Proposals to be considered by the Consortium must be sponsored by a
member of the Consortium.  When a major proposal is put forth, it will
go through the following process:

To be considered by the Consortium, a proposal must include a complete
specification of interfaces and functionality.  A "proof of concept"
implementation is not required at this stage.  The specification need
not be originated through a Consortium-sponsored design process.  The
specification should be presented to the Director of the Consortium for
consideration.  The Director will then ensure that the specification is
circulated to all Consortium members, and a one month trial review is
begun.  The goal of this trial review is to determine if the Consortium
should conduct a technical review of the specification, and to allow
Consortium members to prepare sufficient resources to conduct that
technical review.  At the end of the trial review, each Consortium
member may give the Director a Yes/No vote.  A No vote, to not proceed
with a technical review, must be accompanied with comments to explain
the vote.  The Director will consider the votes, and make an informed
decision as to whether to proceed with the technical review.

If the decision is to proceed, then a three month technical review
begins.  The member sponsoring the proposal is responsible for
appointing an Architect for the review, and each Consortium member is
entitled to appoint one person to a Review Committee.  During the
review, as issues are raised, it is expected that members of the Review
Commitee will vote on how to resolve the issues.  The Architect will
consider the votes, and make an informed decision.  The review will be
conducted primarily by electronic mail; one or more mailing lists will
be established and maintained at MIT for this purpose.  Any number of
people from Consortium members may join these lists, in addition to the
Review Committee and Architect.  Meetings may be called, as deemed
necessary by the Architect or the Director.

At the end of the technical review period, each Consortium member may
give the Director a Yes/No/NotYet vote.  A No vote, to discontinue the
review and reject the specification, must be accompanied with comments
to explain the vote.  A NotYet vote indicates that the specification
either needs substantially more design work, or that the complexity of
the specification requires a longer review cycle.  A NotYet vote also
must be accompanied with comments to explain the vote.  The Director
will consider the votes, and make an informed decision as to whether to
proceed to the public review and proof of concept, or to extend the
technical review, or to dismiss the specification without prejudice and
ask the sponsor to resubmit after redesign, or to reject the
specification.

If the specification is accepted, then a three month public review
begins.  The Director will make reasonable efforts to distribute the
specification, primarily by electronic means.  Any issues raised during
this review will be answered by the Architect in conjunction with the
Review Committee, in the same way as during the technical review.  In
parallel with the public review, a "proof of concept" implementation of
the specification should be undertaken, if required.  Proof of concept
will typically require a complete, public, portable implementation, but
a public implementation is not a requirement, and will be handled on a
case by case basis.  Any issues raised during the implementation effort
will be handled by the Review Committee and the Architect, in the same
way as during the technical review.  Once the implementation is deemed
finished by the implementors (having already passed through alpha test
and beta test stages, as appropriate), a final three month evaluation
period will begin.

At the end of the evaluation period, each Consortium member may give the
Director a Yes/No vote.  A Yes vote indicates that proof of concept has
been demonstrated, and that the specification should now be accepted.  A
No vote indicates that proof of concept has not yet been demonstrated.
A No vote must be accompanied with comments to explain the vote.  The
Director will consider the votes, and make an informed decision as to
whether to accept the specification, or to restart the specification at
some earlier stage in the overall process.

Once the specification has been accepted, the Architect and Review
Committee no longer control the specification.  Each Consortium member
is entitled to appoint one person to a Standing Committee for the
specification.  The Director will appoint one such person as Chair of
the committee.  The Standing Committee will consider all issues raised
by Consortium members, and vote accordingly.  The Chair will consider
the votes, and make an informed decision.  The Director will have final
authority on all decisions.