[r6rs-discuss] "Steering"

[Anton van Straaten]

Michael Sperber wrote:
> Anton van Straaten <anton at appsolutions.com> writes:
> 
>> If the editors had been required to obtain formal approval from the 
>> community for the various pieces as they were being developed, 
>> variations on three desirable scenarios could have played out:
> 
> Both you and I would prefer greater community involvement, so I don't
> think we have a conflict.  

There seems to be general agreement on this, which is good.

> However, I have yet to see a design process where community involvement
> is a substitute for a smaller group of people writing a coherent
> proposal.

I didn't mean to suggest otherwise.  However, as others have also 
suggested, proposals could also come from subcommittees or working 
groups, i.e. people other than the appointed editors.  That worked out 
well in the case of the R6RS formal semantics, for example.  Unicode 
also benefited significantly, but more informally, from outside input.

The R6RS editors had many roles, some of which might be more 
productively delegated beyond the Editors Committee: they were 
designers, authors, editors, voters, contributors of prior academic 
work, advocates for the approaches of particular implementations, and so 
on.  This all puts a heavy load on a small group of editors, and was a 
factor in at least a couple of the resignations.

>> There was a serious procedural problem with the R6RS process, in that 
>> most of the people it was supposed to "make happy" did not have much 
>> influence on the process.
> 
> On this, I disagree.  You're right that the formal influence was small.
> Yet, the editors spent a great amount of energy on trying to cater to
> comments made on the R6RS SRFIs as well as the formal comments, throwing
> overboard many proposals and aspects of the report dear to the heart of
> some of us.

I agree, a great deal of this did take place.  My comment that 
non-editors "did not have much influence" may be an overstatement, but I 
still see a real point here.  For example, the editors made many 
decisions outside of the R6RS SRFI process.  Partly as a result of that, 
when the first full R6RS draft was released, many aspects of it were 
being seen by the rest of the community for the first time.

Increasing the formal influence that the community has on the ongoing 
process, beyond just a ratification vote at the end, would help avoid 
the need to gain approval after the fact from the community for a large, 
interrelated set of changes.  It would also require that changes and 
features be more clearly motivated in advance of their being made.

> A prime example of the limits of happiness is, of course, the records,
> which apparently made many people unhappy. 
...
> Design a record system - see if makes *me* happy.

Yes, that's a big discussion all on its own.  There's no doubt that 
there are real barriers to reaching consensus on both technical and 
taste issues, and the record system is one of the many good examples of 
that.

Still, the R6RS record system is also a good example of what I'm getting 
at - it was ambitious, multi-layered and relatively complex, because it 
attempted to satisfy multiple sets of requirements from different groups 
of users, and it did so by providing multiple overlapping feature sets. 
  Even with the R6RS Records SRFI, this made for a big pill for the 
community to swallow, particularly without experience of using the system.

I trust I'm preaching to the choir when I say that bundling such a 
system into a larger report, along with a number of other such big 
pills, and having the community vote only on the entire package, is not 
an approach that should be repeated.

(As an aside, it's worth noting that Scheme is not alone in the struggle 
to find record system happiness.  Consider Haskell, which has a rather 
simple record system, a.k.a. "Datatypes with Field Labels" as specified 
by the Haskell 98 Report.  This system is widely considered to be very 
limiting, as a web search for "haskell records proposal" illustrates. 
However, Haskell's approach to the problem was to standardize this 
simple but limited system a long time ago, and a better one hasn't yet 
been widely agreed on.  There are lessons for Scheme in this, although 
conclusions could be drawn in more than one direction.)

> Moreover, I invite you to look for
> the signs of outrage, and clear and unanimous unhappiness that the
> editors, as well as the clear and unanimous consensus on an alternative
> design.  If it's there, I didn't see it at the time.

Unfortunately, some of the reaction against the R6RS process manifested 
itself in disengagement, so lack of visible outrage was not necessarily 
a good sign.

I want to be clear about one thing: in raising these issues, I'm trying 
to be constructive, in the interests of improving the process in future. 
  If I'm mischaracterizing anything, please do correct me.  On the other 
hand, I don't think it should be necessary to justify or defend the 
previous process, unless it somehow has a bearing on the design of the 
future process.  The previous process was a response to a particular 
situation.  We're facing a new situation now, and we have the luxury of 
benefiting both from the technical work that went into R6RS, as well as 
the process experience.

Anton