John:
In my case, at least, it's not so much that the SRFIs are
unpolished, as that they only handle part of the problem, the
part I myself can see clearly. The SRFI discussion provides for
the transition from mere opinions to actual positions that can
then be debated and hopefully resolved.
That is indeed the main value of the SRFI process, but if the scope of a
SRFI is too broad or the problem is too vast to be understood in a
reasonable amount of time, we don't have the time and energy to do a
proper review. The scope can be hard to get right. Empirically, reducing
the scope has consistently led to more successful SRFIs.
Arthur:
Yes, I agree, and I apologize for the unpolished language of my
message.
IMHO your message was fine.
John:
(Of course there is also the problem that people don't notice
there is a SRFI they want to comment on until they hear that it
is about to finalize. I don't know what to do about that.
Likewise there is the problem of insufficient resources.)
Arthur:
I keep thinking that there must be a way to help solve some of our
problems with bribery. More stickers, anyone?
Unfortunately bribery cannot solve exhaustion. Our regulars worked very
hard all 2019 and 2020; by the second half of 2020, it seems most of us
had become overwhelmed.
My unpopular suggestion is to stick close to the core language in the
relatively heavyweight, big-design-up-front RnRS and SRFI processes, and
use more lightweight approaches for ordinary library design.
Marc:
The old language in the SRFI process seemed to imply that, for quality
reasons, the 90-day deadline is needed. I'm not at all convinced about
this, so I like your new language better. I see that some kind of limit
is useful because the more SRFIs in draft status, the bigger will the
administrative overhead be.
In any case, I do not see time constraints as a major issue with the
current SRFI process. The problem I see is that many SRFIs are
discussed by far too few people. Moreover, the people that have been
involved in discussing SRFIs only reflect a small part of the Scheme
community. The R6RS process was blamed for this, but the same can
probably be said about the current SRFI process. I haven't made any
statistics but I have the strong feeling that the community was *much*
more diverse during the first 50 or 100 SRFIs.
Good points. It comes back to the problem of not enough people/energy.
In a discussion about the inclusion of SRFI 88/89 to Chez, Kent Dybvig
once wrote: "[...] SRFIs are not standards and are vetted, for the most
part, only by people who are interested in the mechanism." I think this
hits a nail on its head. Our reviewers are all biased. Who does review
and examine thoroughly a SRFI they are not really interested in?
If someone is truly apathetic about some part of the language, maybe it
doesn't matter if they don't review a SRFI about that part. However, if
someone is has a strong _negative_ interest, their comments would be
very valuable to hear if presented constructively.
