> Hi, Lassi. You've already done a bunch of infrastructure work to prepare
> for the new Scheme.org and subdomains, including a prototype home page.
> Would you like to describe that here now that the list has been
> established, and advertise the Github repos as well?

It's all in public repos here: <https://github.com/schemeorg>.

The two main repos are:

* schemeorg -- This repo contains a full description of all current
Scheme.org projects. The master file that drives everything else is
"projects.scm". Each project is associated with exactly one direct
subdomain of scheme.org: for example, the "doc" project maps to
"doc.scheme.org", the "api" project maps to "api.scheme.org", etc. All
nested subdomains of the form "*.doc.scheme.org" also belong to the
"doc" project, etc. For example, if Fantastic Scheme was hosted under
scheme.org, its website could be at fantastic.scheme.org, and version
control under git.fantastic.scheme.org.

Each project is responsible for bringing its own servers (usually that
means a Linux VPS running suitably configured web server software). A
VPS doesn't need to be dedicated to one project; nginx and other web
servers allow easy setup of virtual hosts so one VPS can drive any
number of low-traffic domains and subdomains.

When a project has a server set up, then A/AAAA or CNAME records for
that server are added to "projects.scm" and "dns.sh" is run to
re-generate the "dns.zone" file. Our domain registrar, Gandi, has a
wonderful DNS API whereby we can directly upload a zone file using
"dnsput.sh", making DNS administration easy. If you read at "dns.zone",
that file is exactly what goes onto the DNS server and shows the current
state of Scheme.org at a glance.

Each project is associated with one or more individuals who can be
contacted in case of questions or problems.

* linux-configurations -- This repo holds the configurations for the
current Debian Linux VPS that runs the Scheme.org web server. The main
config is written as an S-expression which a small Scheme program
<https://github.com/lispunion/lander> turns into an Ansible
configuration. Ansible is then run to push the config to the server. I
didn't write an Ansible config directly because its native config format
consists of deeply nested directories full of little YAML files, which
is hard to edit. Nginx configuration files are similarly hard to edit,
so "nginx.scm" generates that stuff. Things are getting slightly hacky
at this point, and there's some repetition in the main config
"schemeorg.scm" but it definitely beats manual configuration and the
native formats for convenience. We can gradually develop these tools
into a more polished form.

It might be a good idea to standardize on Debian Linux for all the
"community-owned", consensus-driven servers. Debian is well-known among
schemers, and it would be the same familiar environment everywhere. For
subdomains that are operated by a particular group for their own project
(not consensus-driven), that group can of course use whatever software
they want.