[Sorry about the long delay - this fell through the cracks because the
topic is complex.]

>> Not every contributor needs Docker. We can just use it on the server,
>> or for CI.
>
> When you say 'contributor', are you meaning someone who looks after,
> e.g., the guide (https://github.com/schemedoc/guide) as a whole, or
> someone who might contribute a single page to the guide?
>
> I was thinking of filling out/adding some pages to the guide. From the
> perspective of contributing a single page, I would want to simply submit
> a single asciidoc or markdown file, and have that incorporated somehow
> into the process of building the static pages.

Agreed - we should make this easy.

> For the person looking after the guide, they would need some appropriate
> infrastructure to generate static pages ready to be uploaded to the
> server. That should be whatever is easiest for them to manage.

Yes.

For the next 2-5 years, we must rely on a bunch of tools that are not
written in Scheme.

The more I keep using this motley crew of tools from Unix, Haskell,
JavaScript, etc. the stronger grows the dream of an all-Scheme
toolchain. The Lisp and Smalltalk traditions easily lends themselves to
a portable virtual machine, so you can transport ASTs or bytecode
instead of x86 machine code. This is a huge win on many fronts. It is
the only sustainable long-term model.

Eventually we have to move to "all Scheme" or at least "all lambda". The
mounting technical debt will demand it - I believe that moving x86 code
and Unix userlands around the internet is intrinsically unsustainable.
The ship is too big, too slow to steer, and is leaking in too many
places to plug them all. It will keep going for another decade but you
can already note buzzwords like "supply chain attack" and "deprecation
warning" being thrown around with increasing regularity. This will get
steadily worse. We're lispers, and Lisp is fundamentally about sanity
and innovation, so it's time we do right by our legacy and return to the
front guard on this issue as on many others.

The Unix and Haskell traditions don't have the same historical
background and hence haven't done the necessary preparations; what they
must do instead is transport Unix userlands using something like Docker.
Their machine language is fundamentally x86, not lambda calculus or
bytecode. Hugs (the Haskell interpreter) hasn't been maintained in ages.
JavaScript still has hope for a simple portable VM, but going for an
all-JS toolchain is decidedly un-schemely and is likely to be no easier
in the long run than an all-Scheme toolchain.

So for the time being, we're stuck wrestling Docker into doing our
bidding. For machines that don't have Docker, the necessary Unix
userland must be recreated from whatever package managers and tarballs
one has at hand.

> Based on the second part, there perhaps needs to be some guidance for
> anyone creating individual pages on how best to do so - do we settle on
> asciidoc or markdown or support both? Permit images/icons?
> Source-highlighting? Diagramming tools?

Scheme.org is fundamentally divided into two kinds of subdomains - those
owned by a group (e.g. gambit.scheme.org), and those that are community
owned.

I believe the only sustainable way to run the community owned sites is
that they are consensus driven. By human nature, consensus tends to be
leader-led for complex decisions and egalitarian for simple decisions.

At the moment you are the most driven person working on the guide, so
it's best that you do whatever you think is best. Others can then offer
advice or debate if they feel like it.

> Just to follow on from the second part - I'm not sure whether you
> envisage a more community-guided level of contribution, or need a
> 'leader' for different sections.

IMHO it's best to have a microkernel model, where the www.scheme.org
front page is as formally run (and minimalist) as possible, and the
other subdomains are as informal as possible.

This is all volunteer work, and that means people come and go. Often a
maintainer will go out of reach. If we have a formal leader for each
section, that will get complicated - how do we determine whether the
leader/owner is gone or not?

> For example, if I were to volunteer to
> 'take care of' the Scheme Guide section, that could mean:
>
> 1. producing a set of adoc or md pages, ready for someone/script else to
> process into html and upload to the server;
>
> 2. producing a set of static pages, with appropriate styling etc, ready
> for another person to upload to the server; or
>
> 3. producing the pages and completing the upload to the server.
>
> The last two would be affected by standard ways to layout the repos.

I'd prefer if everyone can do anything, and let informal social
conventions take care of it as they have thus far.

My policy has been to give repo and ssh access to people who are known
on Scheme mailing lists, IRC, GitHub, etc. IMHO the right policy will
always be that access is rationed by personal relations according to a
"web of trust".

According to the microkernel model, www.scheme.org should be rationed
more than the others and run quite formulaically according to clear
rules, but we haven't had time to properly set that up yet.