[Ratification-discuss] *Cough*

[Alan Bawden]

   Date: Thu, 05 Apr 2007 17:56:00 -0700
   From: Thomas Lord <lord at emf.net>
   ...
   What the Steering Committee learns about the draft from a "yes"
   outcome in the proposed process is only that, minimally, nothing in
   the draft is sufficiently bad as to offend a supermajority.  They
   *don't* learn that all of the important details of the draft are
   pleasing to a supermajority.  Yet, it is that latter condition that
   I hope would be the aim of the process.

Well the Steering Committee (in my unofficial opinion) isn't
-directly- interested in learning the "why" of the vote, but yes, we
do think it would be good if the Editors and everybody else got as
much useful information out of the vote as possible.  That is why we
borrowed the ANSI practice of saying that a "No" vote must be
accompanied by an explanation of why the voter is voting no.  The idea
is that if the standard fails, the Editors should know what issues
they really need to address if they want to prepare another revision
and try again.

But this doesn't address your concern, as I understand you.  You're
saying that even if the standard is ratified, you want people to be
able to know which parts of the standard were more popular with the
voters that which other parts.  Do I understand you correctly?

We -could- require an explanation from the "Yes" voters as well as
from the "No" voters.  My instincts tell me that your average "Yes"
vote won't come with a very useful explanation -- it is the "No"
voters that tend to have interesting reasons for voting "No" -- but
I could be wrong about that.  I'd be interested in what other people
think about this.

   Why not, then, look for a finer grain way to inform the
   ratification process, ideally one that soundly and quasi-officially
   records wide-spread agreement on uncontroversial changes?  If this
   were to lead to a reconsideration of the charter, and the creation
   of alternative routes to formal standards, well, so be it.

This paragraph I don't understand.  We've got a proposal on the table
for how the Steering Committee will decide whether or not to ratify
what the Editors submit as R6RS.  Are you proposing something you'd
like to change about that procedure?  It gets hard for me to see such
a proposal when you veer into talk about "reconsideration of the
charter".

   In the alternative, if R6 really represents a kind of "Common
   Scheme" -- an agreement among a set of implementors who are each
   represented on the editorial committee -- then why take a community
   vote at all?

Because a programming language standard isn't just something that
implementors agree to implement, it is also something that serves the
needs of users.  If R6RS is going be a success it has to be acceptable
to -both- users and implementors.  Implementors also care (in theory
anyway) about what their users want.  Holding a vote is a rough
approximation towards building the kind of user/implementor consensus
we would ideally like to achieve.  (In my opinion...)

But we're open to alternative decision procedures if you'd like to
suggest any.  As long as it allows the Steering Committee to do what
the charter says we're supposed to do, which is:

 "The Steering Committee should then choose either to finalize the
  drafts or to restart the review process."

Those are our two options.  We could flip a coin if we wanted to.

   I don't mean to be argumentative, by the way.  I simply wanted to
   put the idea forward.

I'm still unclear on what the idea is.  But we're making progress.
Please try again, but try to either (a) keep ammeding the charter out
of it, or (b) make it clear that nothing short of ammeding the charter
can address your concern.

- Alan