Re: tech: logic matters

[David Barton <dlb@SEVERN.WASH.INMET.COM>]

Lojbab writes:

   Why do you think a committe would lead to the resolution of
   personal differences.  Most committees have exactly the opposite
   effect and enhance suhc differences.

*snicker*.  From many years experience on the IEEE Design Automation
Standards Committee, I can guarantee that this is the case.

Permit me to make some general observations on management by design
committee versus management by large body consensus, drawn from
experience both in the IEEE standards arena and from watching the
operation of a Quaker meeting for more than twenty years.

Management by large body consensus tends to the conservative in
official pronouncements, and towards a vague, anarchic "groundswell"
in action.  I remember one particular case in the Quaker meeting,
about having the meeting sanction marriage between homosexuals (note:
the following makes no statement *at* *all* about whether this is good
or bad --- it is intended as an example of interaction.  I suspect
that this would be clearer in Lojban than in English).

One homosexual couple came to the meeting and requested that the
meeting sanction their marriage to each other, and that they be
"married under the care of the meeting" (the official Quaker phrase).
This caused a good deal of discussion and consternation.  As the
discussion wore on (over *months*), it became clear that the vast
majority of the meeting was in favor, but that two or three people
were, in all good conscience, fundamentally opposed.  The result was
that there was no official sanction.  However, a meeting was held in
which the two participants stood and expressed their love and intent
to live together, in fidelity and monogamy, and in which the other
members of the meeting stood and expressed their support and
appreciation (this is exactly the form of a Quaker marriage).
Afterwards they were treated by the members of the meeting as a
married couple in all respects (right down to a single entry in the
meeting directory).  Thus: no "official" sanction, but everyone did
what the vast majority wanted.

I contrast this with the recent re-standardization of the VHDL
language (a computer language for digital design) within the DASC.
This was accomplished by the VHDL Analysis and Standardization Group
(VASG), which has the approximate status of the "academy" under
discussion here.  It analyzes the issues (usually in subcommittee ---
the group is quite large), and puts out a new standard for ballot.
The ballot standards are quite severe --- any IEEE member may
participate, and notice of the ballot must be distributed as widely as
possible.  Of distributed ballots, 75% must be returned, and of those
75% must be in favor (a "supermajority" by any definition).

The restandardization effort included a large number of proposed
changes (by coincidence, restandardization in the IEEE occurs every
five years).  The changes finally included in the language were,
measured against the scope of those proposed, extremely conservative.
The process was highly political, and many of the votes were close.
The final result was overwhelmingly approved by ballot, and the new
standard was in place by 1993.

The result?  *No* vendor has completely moved to the new version of
the language.  That's right, *none*.  Some of them have instituted
some of the changes, and some experimental versions exist; however,
three years later (and two years from the next re-standardization
effort) there is virtually no support for the changed language.  The
community as a whole still uses the 1987 version of VHDL.  Vendors say
the demand for the new language does not justify their investment in
upgrading their tools.  Some have announced plans (some announced
plans almost immediately), but they keep on getting put off.
Preliminary discussion for the 1998 restandardization centers around
simplification, so that vendors will be more apt to move to the newer
version.  And VHDL continues to grow; however, because different
versions implement different parts of the *new* language, portability
is degraded.

Now, the lesson of this is not that consensus is good and that a
standardization committee (academy) is bad.  It is that you need to
select the process that fits your needs.  Consensus would have never
created the VHDL standard in the first place (in spite of the entire
community crying out for a standard of some sort), and I belive that
the new restandardization is likely to be closer to the mark.  The
question is, which of these cases best fits the needs of Lojban.

In my opinion (and only my opinion), the consensus approach is better
for our purposes.  If we start from a solid baseline (I may be new,
but from what I have read in the reference grammar, the present
baseline qualifies), then we *want* official pronouncements to be
conservative, but groundswell changes to be applied.  For one thing, a
conservative official corpus gives people an unmoving target to aim at
for teaching and learning.  And asking for groundswell for changes
means that more people will be speaking the language, and that changes
will reflect the needs of the *speakers*, not the language design
committee (academy).  It seems to me that these are the
characteristics we want out of a change process for Lojban.

All of the above is my own opinion only, as a newcomer to the
community.  Please regard it as such.


                                        Dave Barton <*>
                                        dlb@wash.inmet.com )0(
                                        http://www.inmet.com/~dlb