Voting

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

Well, that's pretty disappointing.  I was hoping that if I jumped in and
did all the moderating, all the proposing, all the bookkeeping, and all
the writing on the new document (accepting, but not really depending on,
any offers of help), then the rest of you could at least keep up with
the reading and could vote on, say, five specific proposals per week if
they are small ones.  Maybe that was too optimistic.  Several of you did
warn me that you had real jobs that would require a certain fraction of
your time.

For the record, the ISSUES.TXT file now contains 37 proposals from
Steele's list that I believe are not very controversial (though I'm sure
we'll get a few people making random suggestions on each), 27 relatively
simple proposals on issues that have been raised since December, 24
relatively simple proposals that are likely to requires some discussion
and serious thought, 13 smallish issues waiting for proposals, and 10
big issues requiring complex proposals.  Many of the things in the first
two categories have been discussed before and argued to near consensus;
the "likely to require some discussion" things were dropped with no real
convergence.

If we set aside the big things (object-oriented programming, errors,
eval-when, and so on) and we assume that someone comes up with
reasonable proposals for the smaller issues that need them, and asuming
some small amount of growth in the set of issues, then we've got to
decide maybe 70 easy questions and 40 harder ones.  Suppose we bundle a
couple of the easy issues in with each of the hard ones.  That give us
maybe 40 batches of issues to decide.  If we give each batch five weeks,
that comes to about four years.  And then we can start arguing about
errors and objects and the rest of the hard stuff.  I can guarantee that
if we move at that pace, none of our decisions will be affecting
ANYTHING for years to come.  Common Lisp might survive, but it will be
no more standard than it is now.

If the rest of the technical committee is equally overloaded, we'll have
to rethink this whole thing.  Maybe instead of voting on these things a
few at a time, at the end of a period of debate, I should just whip
ahead trying to resolve these things, putting proposals with
recommendations onto the list, and when all 110 of them are on there,
then we ask the technical committee to approve the whole thing or to
send a few issues back for reconsideration.  I might be able to get this
all done by December, and then the rest of you could take however long
it takes to make a decision.  Of course, that would mean that there is
no feedback from the technical committee to the community until the
process is over.

Or maybe we shouldn't try to decide individual proposals officially.
I'll ask for guidance, write a spec acordingly, and then we'll have a
big vote on the spec.

Or maybe we should just hang it up and admit that this sort of thing
can't be done by a committee, and maybe it can't be done at all.

The rest of you should let me know what you want to do about this.  I
can put in a large amount of work for a while, maybe as much as a year,
but when it comes to making decisions we all have to be involved, or so
goes the current theory.

-- Scott