Thanks for the thoughtful reply!

> Yes, it is, isn't it.  Fortunately, I take a rather relaxed attitude to
> received wisdom (which is also big on static types, TDD, and other
> things I don't do much).
>
>     Specs are wonderful, but they should be
>     produced iteratively with users in the loop. With no field testing
>     before finalization,
>
> Hardly my fault.  The point of the pre-finalization process is to give
> people the opportunity to do functional testing.
>
>     the process is uncomfortably waterfall-like. This
>     is an argument that several experienced schemers have made about
>     current
>     SRFI practice.
>
> They are of course free to write their own SRFIs however they wish to.
>
>     I do use the SRFIs I wrote, and while I think they turned out okay I'm
>     not satisfied with the process of how they were made and the fact that
>     changes can't be made to them anymore.

I know what you mean, but our people don't have the requisite energy to
do the above things.

People don't use these opportunities because the rigor of the SRFI (and
especially RnRS) process is mentally exhausting given the scope of the
work that we are doing. The only way out is to use a less rigorous
process. One where:

- procedures can be added as needed instead of one library at a time

- libraries are not finalized on a timetable

- there is a routine, low-friction way to correct design mistakes

- there is more collective ownership and less individual responsibility

- speculative work can be committed and retracted after a few months

SRFI as currently practiced can accommodate all of the above things, but
all of them are demoralizing to do in the context of SRFI, and doubly so
in the context of RnRS.

>     Scheme Live would fix these problems. Any given individual doesn't need
>     to have time for everything if it's a group effort. The beauty of the
>     approach is that the spec and code writers are also the main users.
>
> Except those are different skills and not everyone has all of them.
> "Scratch your own itch" is fine in theory (SRFI 179 is a good example)
> but not always feasible in practice.

In a less rigorous design process individuals can still serve different
roles if they like. It's still useful to write specs, perhaps even to
start by writing a spec before there's any code. But to avoid exhaustion
and stagnation due to perfectionism, most aspects of the process should
be more lenient and flexible.

>     I still don't understand why you are so drawn to finalizing specs first
>     and then having other people implement and use them.
>
> I don't: that would indeed be a waterfall.  I *write* specs and ask
> other people to implement them and still other people to use them.  They
> aren't finalized until at least the implementation is written and
> hopefully not until at least some early adopters have used them.  But
> early adoption is tricky: people tend to want to adopt only things that
> already work, as they are afraid they'll have to undo what they've done.

Fair enough. But if the users are not showing up, something is amiss. It
may be a communication or trust problem, but social processes exist for
the purpose of solving those, and our current processes, in the way that
we currently use them, are not solving them.

I believe the thing that's missing is collective ownership. You say that
you intend all SRFIs and pre-SRFIs around R7RS-large to be collectively
owned, and I have every reason to believe you. Yet in practice, people
(and especially users) are not taking ownership very much. It seems to
me that the most likely reason is the design processes are too rigorous
for most schemers' available energy levels.

I've seen several people mention in passing that they should write a
SRFI, but due to lack of available time and energy, or due to the rigor
expected from the specification, they haven't. There's a need that isn't
being met.

We can always publish libraries in Snow and Akku, but those don't enjoy
any kind of official standing. The Lisp community has a 30-year record
that shows what consistently happens when all libraries are available on
a level playing field: cohesion at the language level keeps eluding.

>     What does that mean for those pre-SRFIs -- will they be up for grabs
>     for other people to continue the work and submit as SRFIs?
>
> Absolutely.  And of course I expect the implementers to deviate from the
> specs, hopefully discussing the changes with me (if I am still available).

Good to hear that they will continue to be developed. You've put a lot
of good work into them.

We appreciate your continued presence, effort and expertise.

>     Scheme Live should have as a main goal that the libraries make one
>     whole.
>
> It sounds to me like you *want* them to converge, but I don't see how
> you mean to get there.  Coherence, like security, is hard to retrofit.

Yes, that's right.

I would try to get there by having everything open to change, but
publishing yearly stable releases of the API. This would give a balance
where anything can change in the cutting edge version if there's enough
of a need, but at the same time, the existence of the stable versions
and the common ownership would bring social pressure against changing
things frivolously and too often. This is not perfect but I don't see a
way to do better than this; alternative ideas are welcome.

>     Not sure I know this pain. Haven't found any fundamental problem with
>     it. There are better tools than `git filter-branch` now.
>
>
> Tell me how, then.

`git subtree` is now built in; https://github.com/newren/git-filter-repo
is third-party but even better. Neither relies on submodules.

> I think that separate ownership has led to separate repos.  I have never
> cared about ownership: on the contrary.

You're probably right. It's good to have agreement on common ownership.