--- Begin Message ---
On Wed, 2009-02-18 at 10:20 +0100, Michael Sperber wrote:
> Grant Rettke <[email protected]> writes:
>
> > As an outside looking in only through the window of the candidates
> > statements; the most interesting thing to me is their notion of what
> > "steering" entails, and why.
>
> I think the primary job of the Steering Committee is to enable the
> Scheme process to make progress, as opposed to running that process
> itself. (That shouldn't prevent the Steering Committee members from
> changing hats once in a while, but you get the idea.)
>
> From my point of view, this has two aspects: A procedural aspect, and a
> a personnel aspect.
I tend to agree, with a caveat or two. The steering committee has to
find ways people can work together in a pretty complicated engineering
project. I remember from the IEEE process what a chore that was, and
there we had an established procedure to start with. There's no
question that procedure + personnel are crucial to the steering
committee's job.
But I think the Steering Committee also has to provide some direction.
Exactly how much is a pretty gray zone. In the first place "progress"
is sometimes illusory. Many things done in the name of progress are
counterproductive. Things shouldn't be changed just to make the next
version different. Incompatible proposals should NEVER be reconciled
by adopting a compromise worse than either on its own. And generally
things should be changed when *not* changing them causes bigger
problems than changing them.
The steering committee doesn't and shouldn't say how a problem should
be solved - but it should be attentive to actual people with actual
problems (including implementors, users, educators, and researchers)
and provide feedback to the editors about which problems are
considered "important."
The steering committee doesn't and shouldn't say what changes are
"acceptable" - but should probably require answers to questions about,
for example, how much code a given change will break, whether it will
invalidate the engineering foundations of entire implementations,
whether it creates ambiguous syntax or semantics, and what kind of
performance impact it will or should have on existing and future
code. Nobody should be voting for (or against) changes without
knowing what impact they're going to have.
> I think in the evolution of the language, it
> will continue to be the case that small groups of people will need to
> get together, agree amongst themelves, and hammer out documents to
> present to the community, and it is crucial that these groups work
> efficiently.
Agreed. "Never underestimate the power of smart people in small groups"
as a lead engineer I used to work with liked to say.
Bear
--- End Message ---
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
