New subdomains Lassi Kortela (02 Jan 2021 16:44 UTC)
Re: New subdomains Arthur A. Gleckler (02 Jan 2021 18:16 UTC)
Re: New subdomains Arthur A. Gleckler (02 Jan 2021 18:50 UTC)
Re: New subdomains Lassi Kortela (02 Jan 2021 19:30 UTC)
Re: New subdomains Arthur A. Gleckler (03 Jan 2021 00:26 UTC)
Re: New subdomains Lassi Kortela (03 Jan 2021 00:40 UTC)
Re: New subdomains Arthur A. Gleckler (03 Jan 2021 00:57 UTC)
Re: New subdomains Lassi Kortela (03 Jan 2021 13:24 UTC)
Re: New subdomains Jakub T. Jankiewicz (03 Jan 2021 07:38 UTC)
Re: New subdomains Lassi Kortela (03 Jan 2021 14:33 UTC)
Re: New subdomains Jakub T. Jankiewicz (03 Jan 2021 17:18 UTC)
Re: New subdomains Lassi Kortela (03 Jan 2021 18:46 UTC)

Re: New subdomains Jakub T. Jankiewicz 03 Jan 2021 07:38 UTC

On Sat, 2 Jan 2021 21:30:26 +0200
Lassi Kortela <> wrote:

> > <> - Frequently Asked Questions
> >
> >
> > Do we have a separate group of volunteers ready to work on this?
> We elmost certainly don't have a completely disjoint group from existing
> volunteers. There's currently a FAQ at the Scheme Community Wiki, but it
> was suggested that a separate FAQ entry helps with discoverability.

One note from me it will be really hard to optimize (SEO) of the website that
important information is on sub domain, it will hurt when
optimizing and collecting links and it will hurt any subdomain. That's why
when people write blogs if they know about SEO and they want to promote the
page they pick up about not The second is
different website and will not benefit for good ranking of

> > The front page should *not* list only implementations that have a
> > <> subdomain.  That would be a perfect
> > example of Conway's Law at work: the way we present important
> > information would be twisted to fit the organizational structure we
> > have chosen. We shouldn't privilege those implementations in any way
> > other than by giving them a subdomain.  Yes, we should keep a list of
> > every implementation we can find, but that list, or a link to it,
> > should be on the home page — not the subset that have subdomains.
> That leads us back to the question of whether or not we have moral
> authority to make subdomains for implementations who have not asked for
> one (even if they are just redirects).

Sub domain for implementation that is not redirect is perfect but IMHO
sub domain that is just redirect make no much sense to me.

It seems that it just sub domain so it meet the main rule that was pick of
having sub domains as URLs on main page. Which is as I've wrote bad for SEO
and hard to optimize.

> > Frankly, this division into subdomains is becoming ridiculous.  Pages
> > and URI paths are a perfectly adequate abstraction, and groups manage
> > to organize themselves quite well around them using tools like Git. 
> > should be a unifying force, but breaking every tiny topic
> > into a separate subdomain is either going to Balkanize us or it's
> > going to create artificial boundaries to cooperation within a single
> > community of volunteers, neither of which is a good outcome.
> I appreciate the unfiltered feedback! It's a good thing. If others
> lurking have unfiltered comments as well, please feel free to send them.
> The groups working on different subdomains don't all need to be
> separate, and in practice, the groups working on community subdomains
> would overlap greatly. Subdomains give us the possibility of isolating
> technical resources, and that gives us the possibility to let any two
> groups work completely separate from each other if they so with. But the
> mechanism doesn't by any means *mandate* this policy. For example, most
> of the subdomains currently have git repos under
> It's easy to give every collaborator
> access to all of those repos.

GitHub pages have separated directories for different repos for same users
and it work fine. I don't see the reason why can't have
directories that are git repos.

> Likewise, the linkage from the front page is so seamless,
> especially if the community subdomains use the same CSS stylesheet, that
> it looks quite unified to a casual user of As far as our
> community-driven sites are concerned, subdomains are more of a safeguard
> than an absolute divider.

It not make much sense to me to have sub domains if the websites will look
the same. There are lot of benefits of making it just different path of same
domain. It will probably take some work to make they directories separated,
but I'm not an admin of DevOps so I'm not 100% sure how hard it would be.

> > P.S.: Rather than giving out subdomains for every conceivable
> > subtopic, I'd rather give them out to separate groups that are already
> > organized around a topic, e.g. around a specific Scheme
> > implementation.  When a separate group has already been formed, being
> > able to operate completely independently, which is the forté of the
> > subdomain, is important.  Otherwise, it creates too much friction for
> > the volunteers who are trying to help with many different topics, and
> > it creates the appearance of division where we're trying to do the
> > opposite.
> I think that arrangement would display Conway's Law more strongly.
> By all means, we should give to the people working
> on Fantastic Scheme, and so on. But for resources around a broad topic,
> like documentation, it would confuse users if we have 2 or 3 different
> documentation sites instead of one. Inadvertently using Conway's Law to
> divide resources is what the Scheme community has done so far. It's
> unifications like RnRS and SRFI that have probably done the most to
> improve the Scheme community.

I don't say that sub domains are all bad, but they should not be used for
everything just because that was decided at the beginning.

> If we encourage the community to keep the divisions even as resources
> are placed under, it will perpetuate the existing situation,
> where there are N different partially maintained sites for any given
> topic. We can still do that, and if e.g. we have two groups who strongly
> disagree on how to present documentation, we probably should give each
> group their own subdomain to experiment with it. But whenever there
> isn't a clear disagreement, and the topic is something generic like
> documentation or netowrking or libraries, we should encourage everyone
> around that topic to join forces.

It seems that right now different sub domains are just single html page they
don't even have structure so it can be just faq/index.html (accessed with
just faq/) making thing like FAQ separated domain make no much sense and it's
overkill and when someone search "scheme faq" will need to be
optimized separately. Have like 10 domains to optimize for search engines
will be really hard to make it right.

Jakub T. Jankiewicz, Web Developer