Voting

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

Well, my model was that most of us would follow and participate in
the technical debates taking place on the Common Lisp mailing list as
they happen, and that there would not normally be any need for a
separate period of technical debate just among ourselves.  Issues would
go to the "technical committee" when the community, including us, seems
to have converged.  That's the way it has worked in the past.

Given that model, the decision making by the technical committee is
mostly a matter of rubber-stamping an existing consensus (which we have
already participated in forming), and occasionally making hard decisions
where the community has deadlocked and someone has to decide.  The
rubber-stamp issues could fly by pretty fast, and on the harder ones
we'll have done most of the arguing already and there won't be much more
to say before voting.

Another function is to take a last look at the proposals and make sure
that, in their final form, they make sense, but if we were to spot any
problems, my view is that the public discussion should be re-opened on
that issue, not that we should do a lot of debugging and tuning behind
closed doors and present the community with decisions that they have not
seen in advance.  Again, it was my hope that the "last call for
comments" period (always at least a week long) could be used for this
purpose.

All of that would work well, I think, and would not take a lot more of
anyone's time than any other way of doing it, but it does require that
most of us keep up with the ongoing discussion (within a few days) most
of the time.  If people really feel that they must batch up Common Lisp
activities and give this stuff a burst of time every month or two, the
above model can't work.  In that case, I guess the only choices are to
submit proposals in large batches, with 4 - 6 weeks of decision time for
each batch, or to pipeline the thing, submitting a small bunch of issues
every week, but not expecting a decision on any given bunch until 4 - 6
weeks after it is submitted.

The problem with both of those models is that it totally separates the
activities of the technical committee from those of the community at
large.  When the community is debating some issue, they won't have the
benfit of our feedback (except for mine).  Then, when the community
believes that something has basically been settled by consensus, the
issue disappears into limbo for a long time and nobody can count on the
answer.  If we end up rubber-stamping the decision, fine.  But in many
cases, if we high-powered experts look at some issue for the first time
weeks after everyone else has finished with it, one of us will spot a
problem.  Then we either present the community with a decision that is a
total surprise to them or re-open the public debate.  (And if we do not
follow this second debate in real-time, we iterate again, 4 - 6 weeks
later.)

I realize that the volume of mail has been very great in the last couple
of weeks.  I've been trying to whip the community into some sort of
movement, and haven't wanted to be too authoritarian in telling people
to shut up when they start arguming among themselves about an
alternative that is clearly not going to be accepted.  My feeling is
that as the process starts rolling, some of this will simmer down, but I
could be wrong.

If there's some way I could make it easier for the rest of you to follow
the debates in real-time, we could try that.  Some of you have appointed
assistants who would follow the debate, filter the important mail to
you, and flag anything that wants your immediate input.  If it would
help (and only if, since it's still more work for me to do), I could
send out a terse summary of the worthwhile points that have been raised
at the time of the "last call for comments".  Those of you who choose to
could read that instead of all the rambling messages and discussions of
issues not related to the cases at hand.  If a couple of others on the
committee are reading all the mail, they could flag any unjustified
omissions in my summary.  Note that I would only send this to the
Cl-Technical mailing list.  If this were sent to Common-Lisp, it would
be politically impossible for me to say that "X suggested solution Y,
which clearly is a loser" or just to ignore X's suggestion altogether.
I've already received some flames for the little "the consensus seems to
be" summaries that I've put out with the proposals.

-- Scott