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.