planning Arthur A. Gleckler (24 Nov 2020 20:11 UTC)
Re: planning Lassi Kortela (24 Nov 2020 20:59 UTC)
Re: planning Arthur A. Gleckler (24 Nov 2020 21:41 UTC)
Re: planning Lassi Kortela (24 Nov 2020 22:07 UTC)
Re: planning Arthur A. Gleckler (24 Nov 2020 22:11 UTC)
When to publish the www.scheme.org front page? Lassi Kortela (24 Nov 2020 22:20 UTC)
Re: When to publish the www.scheme.org front page? Arthur A. Gleckler (24 Nov 2020 22:35 UTC)
Re: When to publish the www.scheme.org front page? Lassi Kortela (24 Nov 2020 23:19 UTC)
Re: When to publish the www.scheme.org front page? Arthur A. Gleckler (25 Nov 2020 01:02 UTC)
Re: When to publish the www.scheme.org front page? Alaric Snell-Pym (25 Nov 2020 10:14 UTC)
Re: When to publish the www.scheme.org front page? Lassi Kortela (25 Nov 2020 19:46 UTC)

Re: When to publish the www.scheme.org front page? Lassi Kortela 24 Nov 2020 23:18 UTC

> We should concentrate on getting the home page at Scheme.org into a
> state where it's good enough to put up. Schemers.org is woefully out of
> date and full of broken links, so we should set a low bar.
>
> Here's a proposal:
>
>   * Collect all the current information from |Schemers.org|.
>   * Remove broken links.
>   * Add links to just a bit of new material, e.g. the Scheme Workshop 2020.
>   * Move all the links on the staging page that point to |Scheme.org|
>     subdomains into a block at the bottom, labeling them as needing
>     volunteers to work on them.
>
> That's probably enough to justify removing the redirect |Schemers.org|.

Schemers.org is designed as a monolithic site. Hence its structure is
somewhat different from the factoring into subdomains that currently
presides at Scheme.org.

I'd strongly advise having a 1:1 correspondence between links on the
Scheme.org frontpage and subdomains under Scheme.org. If we do that, the
social contract underlying Scheme.org is WYSIWYG. If we have a
significant number of links on the front page with no clear owner it
obscures the fact that Scheme.org is divided into subdomains, as well as
the fact that each subdomain is governed as an independent unit and
maintained by its own group. The parts of the front page that don't
point to any subdomain become the de facto responsibility of the
top-level Scheme.org admins, who tend to be busy people; being busy led
to the current paucity of updates on Schemers.org. If we want the front
page to stay fresh over 20 years, the admin responsibilities need to be
trivial.

In general, establishing long-lasting principles of governance is like a
game of telephone (https://en.wikipedia.org/wiki/Telephone_(game)):

"Players form a line or circle, and the first player comes up with a
message and whispers it to the ear of the second person in the line. The
second player repeats the message to the third player, and so on. When
the last player is reached, they announce the message they heard to the
entire group. The first person then compares the original message with
the final version. Although the objective is to pass around the message
without it becoming garbled along the way, part of the enjoyment is
that, regardless, this usually ends up happening. Errors typically
accumulate in the retellings, so the statement announced by the last
player differs significantly from that of the first player"

In order for Scheme.org to stay reliable and relevant over decades, a
wide range of people need to be able to trust it, and that can only
happen if the governing principles are extremely simple to the point
that a bright child could understand them.

The temptation is to take the easy way out and freely add information to
the front page like a monolithic website. My job is to be the annoying
guy and continually urge us to avoid this natural impulse.

---

All that being said, copying the existing information from Schemers.org
into a good factoring of subdomains would make a lot of sense. For
example, we don't yet have subdomains for the Scheme Workshops, nor for
events in general. Implementations and libraries don't yet have
subdomains, etc. Mapping out how to represent all of that would be
important for both the near and far future.