[Ratification-discuss] *Cough*

[Thomas Lord]

Alan,

I am proposing:

   1. To keep the aspect of the charter that says, in effect,
       the editor's propose, the steering committee disposes,
       and hoi poloi cheer and jeer.   No changes to that
       arrangement.

   2. To revise the voting procedure of the currently proposed
       ratification procedure.

   3. To revise the envisioned time-line.

   4. To revise the process by which a draft is assembled.

   5. To revise the IT infrastructure used for assembling
       the draft and communicating with the larger community.

I suspect that items (2..5) will lack appeal to most editors and
steering committee members alike, but I will (try once more) to
explain my recommendation.

By way of full disclosure:  I am biased against the current draft.
As nearly as I can tell, the current possible outcomes are to
ratify it on or near the first attempt, resulting in a poor quality R6,
or to plan on substantial revisions, making the current timeline
a bit of a mockery.   This isn't the time or place to explain or justify
my bias.   I think you can see, amidst the noise, that several
posters to the discuss list have raised serious concerns.  I simply
note my bias as my motivation for proposing these process changes.

With my bias comes a certain fear:  while (in my view) the draft
has some serious problems, it also includes some desirable features.
Asked for yes/no votes, an average member of hoi poloi is in a bind:
postpone some long-wished-for improvements to RnRS or insist that
the problems are fixed.   Discussion of the changes in the draft
has been disorderly and noisy and it seems to me that few discussion
list members have had a chance to clearly discuss any but their
particular favorite areas of interest.   Thus, I think that typical voters
are likely to be well-informed on the details of a few changes
made in the draft, and under-informed about the rest.   I thus fear
a large number of under-informed "yes" votes.   For all of their
talents, I would not realistically expect this steering committee -- or
*any* practical steering committee -- to "fill in" for all of the missing
dialog.   Thus, especially in the context of a probable "yes" outcome
to the community vote, I would expect the steering committee to be
biased towards ratification.

If my bias against the draft and my fear of a procedural bias towards
ratification are both justified, then the probable outcome is the
ratification of a poor quality standard (albeit one that contains many
improvements over R5, when changes are considered in isolation).

To avoid that outcome, I suggest considering the structure and
function of the standard and the changes made to it.  It seems to
me that changes relative to R5 break down, in natural ways, to
small issues that can be individually contemplated.   To be sure,
there are dependency relations among changes.   Some changes
are wholly independent (e.g., moving language about the history
of numeric types from the section on numbers to the introduction).
Other changes are one-way dependent (e.g., all motion of procedures
into libraries depend on the basic definition of a library).   Still
other changes, while still somewhat separate, have two-way
dependencies (e.g., changes to the lexical syntax and changes to
the definitions of characters and strings).

The separate but sometimes-interdependent nature of changes relative
to R5 strikes me as very similar to the nature of changes made to
complex programs.   Large changes to programs are, generally, made
in smaller, separate steps.  The dependency relations among changes
to a program are analogous to those among changes relative to R5.

Extending the analogy: consider the difference between receiving
a huge patch that allegedly adds many new features to a program,
vs. receiving a steady stream of smaller patches, each of which adds
a small feature, such that the smaller patches add up to the larger patch.
Surely you would agree that the stream of smaller patches are easier
to review -- easier to check for correctness.   With a very large patch,
and a deadline for applying it, the inclination is all too often to skim
it, judge it largely by reputation, say "Eh, it looks ok," and apply the
patch.

A draft for R6 would be far more convincing and compelling to
more people if it were presented as a series of separately made patches,
each of which was subject to independent review.

At this point, you might be thinking "the editors did just that!"
Indeed, areas of change relative to R5 appear to have been "divvied
up" among editors, each of whom was responsible for drafting
changes in particular areas.   Discussion of those changes happened
on an issue by issue basis and was finalized by at-large voting.  Yet....

Looking at the editor's list archives, I'm not sure that that is the best
account of what has happened so far.   Editors are people too.   They
have finite time and energy.   They have a kind of political motivation
to keep the process moving forward.   It is hard to tell, amidst the
long threads and omnibus votes, whether various changes were ultimately
approved because of acclaim, or because people simply got tired.

Well, if the history of changes made in the draft has produced
a set of changes worthy of acclaim, then it should be able to
withstand the following test:

1. Identify (by self-nomination and convincing statement) a subset
    of hoi poloi who reasonably serve as external reviewers.

2. Present the changes relative to R5 to that group, piecemeal, for
    individual review, discussion, and voting.

A srfi-like IT infrastructure (augmented with membership lists
and voting mechanisms) would help with that.

One might even take that farther:  A procedural revision to the
charter could:

    a. Declare a "final draft series", beginning with R6RSa0 --
        alpha release 0 of R6.   R6RSa0 should be verbatim
        identical to R5RS.

    b. Permit the editors to propose subsequent alpha revisions
        -- R6RSa1, etc. -- to the steering committee for ratification.
       Each proposed alpha revision should be accompanied by
       pointers to corresponding discussion and voting in the
       "qualified community" forums.

Those additional extensions to the process would give legitimacy
to implementations that want to get an early start on new features
while providing their users with some expectation of stability,
legitimacy, and eventual portability.

In some sense, a shift *now* to an alpha-series process would
be far better than if the process has started with an alpha-series
process.   That is to say that R5.92 gives us an excellent context
in which to understand smaller changes, presented in an alpha-release
process:  we have the vision, now let's review the steps to get there.
It might even make sense to, concurrently with an alpha-release
series, have the editors maintain the current draft and produce
5.93.... etc.    (It's easy to propose work for others from afar :-)

Again, I fully understand that this is a pretty out-of-left-field
set of suggestions.   I presume (and regret) that if these suggestions
were simply adopted tomorrow it would be awkward for editors
and steering committee members alike, not least because it would
represent a decent amount of unplanned-for work.   My bias
against the current draft, including what I've seen of the effectiveness
of the discussion list and the history of the drafting, leads me to
make these suggestions anyway.

Is that clearer, now?

-t


Alan Bawden wrote:
>    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
>
>