On 29/11/2020 14:58, Lassi Kortela wrote:
>> 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.

Yeah, that sounds good.

>> 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.

Yes! What subdomain content gets originally published on can be decouple
from what subdomain(s) it appears on, via automated feed processing.

>> 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.

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!)

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

Yeah!

>> 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.

Indeed

>> 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.

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.

>> 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.

Yeah. All we'd need to do is expose the things that subdomains would
like to be able to easily copy, in a way that they can easily copy them.
Git submodules are another option.

>> 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)?

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).

--
Alaric Snell-Pym   (M0KTN neé M7KIT)
http://www.snell-pym.org.uk/alaric/