> That's a good start.  It lays out some high-level
> goals without going into so much detail that the
> implementers' freedom to act is impaired.
>
> Assuming that people like this outline, the next
> important step is for each volunteer to declare
> which concrete subgoals they plan to work on right
> away.  That will help reduce duplication of
> effort, and it can be a morale booster to see that
> other people are excited, too.

We really do have different personalities :)

To me, that's a heavyweight planning process - it didn't even occur to
me that we could go into such detail. The way I see it, a natural split
is at major software boundaries:

- server (graphql server and metadata scrapers)
- client 1 (web)
- client 2 (e.g. emacs)
- client 3 (e.g. repl or command line program)

Dividing these into sub-items is wishful thinking at this stage, and
mainly increases communication/planning costs. If more than one person
works on one item, that's fine but the communication needs to be so
nuanced and frequent that plans or todos do more harm than good.

I just don't speak that language of detailed planning for creative
projects. I've never seen any compelling evidence that it works. At
work, we've always used very lightweight planning processes, and even
those plans we mostly ignored. In small open source projects there's
usually no definite plan. And yet things get done just fine.

Once API and module boundaries have stabilized and we have e.g. 3 API
clients and 3 metadata sources to prove it, then it will be easier to
hand off individual modules. But when interfaces evolve constantly,
delegating work slows things down.

All of the problems that have been brought up in these threads - doing
everything in pure Scheme, having a clear division of modules and
responsibilities, involving new people - I would solve all of them
simply by waiting a few months or talking things out informally.

Are there concrete things that could go wrong _with the end result_ if
we do things in this messy way we have done until now? If so, could we
just address those concerns? If the only concern is that things will
take a few months to stabilize, I don't see that as a problem, because
realistically that's going to happen with any approach. Non-trivial
creative work always takes time until the result stabilizes.

As for onboarding new people, I would suggest that people simply say if
they are particularly enthusiastic about working on something, and then
we find a way for them to work on that. Enthusiasm is the best driver.