> Ah yes, I wasn't thinking about telling people when they see the link,
> but that's a good point. I was thinking about, when somebody browses
> their way off of scheme.org that leads them into the Chicken manual and
> they read
> http://wiki.call-cc.org/man/5/Extensions%20to%20the%20standard#expression-comment
> it should be clear that this is a Chicken extension (albeit SRFI-62) and
> not part of "core" scheme; the fact that they layout of the site changes
> visually is probably the best way of making that crystal clear (but
> changing the styling of the link that originally makes that leap is also
> valuable, too!)

Sure! We can expect e.g. doc.scheme.org to cover many
implementation-dependent features; a clear marker as you suggest would
be good.

> I've nothing against that (I like things that follow neat patterns!),
> but if chicken.scheme.org is just a redirect to http://call-cc.org/ then
> it's still, conceptually (as far as users will see) a link "outside"
> scheme.org.

For users (who aren't observant about URLs) it's indeed the same thing,
but the site should communicate to both users and (current and future)
admins. If we want a simple structure that stays relatively constant
over time, enabling people to know and trust that structure, thereby
making it resilient, it pays to communicate how and why things are
organized. I tend to assume a kind of Murphy's law (game of telephone)
for long-term projects, where values and principles will decay and get
disorderly by default unless a conscious effort is applied to stick to
them. The disorder will in turn start to dissolve the community. Such
disorder is good for creative, divergent projects where the point is to
make new things, but not good for projects where the priority is
conservation.

>> RSS as static HTML sounds workable. Does HTML have some kind of include
>> tag to embed another HTML file (without using things that look and
>> behave differently to the use, such as like iframes)?
>
> Not really, no :-( But many web sites are generated from sources writte
> in Markdown or similar, and those site generators make it easy to
> include HTML at "build time". Doing it statically means that upstream
> changes don't just magically appear downstream without the downstream
> devs doing a rebuild, which can be a bug (things drift out of synch, a
> new link added to the shared navigation will appear on some subdomains
> and not others) and a feature (a breaking change we make by accident
> doesn't break everything, and may not even break anything because
> subdomain teams will notice the breakage when developing and not deploy
> that new version).

The script <https://github.com/schemeorg/schemeorg/blob/master/www.scm>
generates the front page HTML; maybe we could run it in a cron job on
the server. This would also have the advantage that if the cron job is
problematic, we can turn it off and keep statically generating the page,
on other computers if needed. The script would be independent of where
the page is stored, how it's served, and how the script is run.