> Relatedly, I've been wondering in my head whether we should seek to
> agree on some clarity about what gets to be a subdomain.

Thanks for thinking about governance. Good to get more people involved
in that.

> As they are the unit of delegation, subdomains should perhaps reflect
> "organisational" structure - each *publishing entity* gets a subdomain.

Yes. Naturally, many regulars will wear several hats, i.e. contribute to
several subdomains. "One maling list per community subdomain" is a good
rule of thumb.

> This will sometimes only loosely follow a natural knowledge-management
> hierarchy for viewers, stuff like automatically gathered API docs and
> tutorials and so on will probable be produced by different groups/people
> but, in terms of front page navigation, should all go under "Learn" or
> something like that.

Subdomains can also import content from each other and link to each
other. Centralizing machine processing into api.scheme.org would seem
like a good ieda.

> Should we encourage sub-domain sites to have common top-level navigation
> elements and styling? That would make sense to help produce a more
> unified experience, but wouldn't make sense for less "core" things, like
> <implementation>.scheme.org. We need to strike some balance involving:

Yes, common navigation/layout for community subdomains makes sense.

> 1) Making it clear to users when you leave common "Scheme Community"
> territory and go into some more "third party" site, such as an
> implementation page. So they know that statements they find apply to
> that implementation rather than Scheme as a whole.

In which way would we clarify this? Something subtle like a dashed
underline for links might be good, but if the visual cues are very
prominent, people easily get the sense that they're being nannied.

Individual Scheme implementations' websites seem mostly neutral so far,
and don't involve turf wars :)

> 2) Making it easy for users to navigate around within the "Scheme
> Community" zone, without needing to backtrack to scheme.org to find
> their way on to other areas all the time.

Good idea.

> 3) Not putting an unnecessary burden on subdomain groups to comply with
> some style guide, nor a burden on us to maintain a style guide.

The subdomains could work gradually and informally toward a common
style. More like gardening than farming.

> 1) Aliasing sites that already have their own identity under scheme.org
> probably won't take off. Chicken has call-cc.org, what purpose would
> chicken.scheme.org fulfil that a link to call-cc.org from an
> Implementations section on scheme.org doesn't?

I'm still strongly in favor of having a 1:1 correspondence between front
page links and subdomains. The subdomain can be a simple redirect if
nothing else. Schemers.org currently has arbitrary links, and it's not
easy to make out the structure.

I may be a minority of one in this matter; if so, will continue to be one.

> 2) We should write the CSS for scheme.org in such a way as to make it
> easy to include on subdomain sites so that subprojects can use the CSS
> with minimal work (including: we don't go willy-nilly changing the whole
> way the CSS works and adjusting all the classes in ways that will break
> other HTML using the same CSS) to get a consistent look and feel, but
> using it is just a suggestion for subprojects, they can do what they
> want - they will already be aware that there's benefits to "fitting in"
> nicely, we should just provide a way to make it easy for them, and for
> there to be no shame in diverging where appropriate. I'm a bit behind on
> the state of the art with regards to cross-domain requests, so I don't
> know if subdomains can just link to that CSS directly without browsers
> moaning, or if they'll need to just mirror it to their own subdomain at
> site deploy time or what?

I'd put the priority on keeping the www.scheme.org front page simple and
free of dependencies on anything else, just as passing new laws doesn't
change a country's constitution. A little copying is better than a
little dependency, as the Go folks say. There are ways to automate copying.

> 3) We should see if there's some reasonable way to share a top-bar
> navigation between projects in a similar manner, even if it's just that
> we share up the top-bar HTML on its own at some URL so that subprojects
> can suck it into their template system when they build and deploy new HTML.
>
> ...is probably a reasonable tradeoff?
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)?