>     The starting point should be that it's implementation first (or
>     implementation and discussion), and once the implementation
>     stabilizes, a stable specification is the end product.
>
> It's still the case that SRFIs work like that to a fair extent.  The
> main exception is the work that I'm doing: I have time to write specs
> (and I enjoy writing them), whereas writing the corresponding code
> requires not only more time than I have now, but quite possibly more
> time than I will ever have.

I don't believe that the designer-driven approach is the right one. I
know you have invested a lot in to that approach, but there's no getting
around the issue that it's opposed to a lot of the received wisdom
around hacking and agile. Specs are wonderful, but they should be
produced iteratively with users in the loop. With no field testing
before finalization, the process is uncomfortably waterfall-like. This
is an argument that several experienced schemers have made about current
SRFI practice.

Whether one likes to write specs or not (I also enjoy writing them, so I
have stake in both sides of the argument) it would be good to have users
for libraries first, and then graduate those libraries to stable status
after users have deemed them stable, and this should be a slow process.

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 had too much power relative to
other people, and not enough time to arrive at the best design.

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.

I still don't understand why you are so drawn to finalizing specs first
and then having other people implement and use them. What would you lose
in being part of a more open-ended process with the users on board?

> I think what is going to happen fairly soon (after the Orange Edition is
> ballotted) is that I migrate my remaining specs out of
> johnwcowan/r7rs-work and into pre-srfi repos, and then get out of the
> SRFI business altogether.  I will focus on WG2 duties, and will arrange
> SRFIs into ballots based on availability rather than subject matter.

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?

>     A library collection would basically be the same thing, but putting
>     all libraries in a monorepo with collective ownership instead of
>     separate repo per library, each owned by one person.
>
> The trouble with a monorepo is "once mono, always mono"

That would be exactly desirable for Scheme Live. We have to be able to
change not only modules, but module boundaries. Otherwise we're blinded
to important possibilities in the design space.

Current SRFI and pre-SRFI do not have a primary aim to produce one
cohesive language, and corresponsingly one repo per SRFI is a good idea.
Scheme Live should have as a main goal that the libraries make one
whole. [Insert obligatory joke about Buddhist at the hot dog stand.]

> it is a pain in
> the ass to extract a particular subtree into a SRFI repo,

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

> whereas if
> each pre-SRFI is in its own repo it is easy to transfer it to SRFI space
> and archive the pre-SRFI space.  Ownership isn't really an issue:
> everyone who is an owner of the pre-srfi org is also an owner of all the
> individual repos, and there's no reason why everyone who wants to
> participate can't be added as well.  (Of course there will be some
> participants who want nothing to do with GitHub.)

This is fine for SRFI, and if pre-SRFI is to be an exact mirror of SRFI,
then for that as well. The separate repos have thus far led to de facto
separate ownership by way of Conway's Law.