+1 to Jonathan's comments.
I'm worried about many of the same things that Jonathan described. I'm not wedded to the subdomain approach, but I do see the value in making clear divisions between parts of the overall site so that different groups of volunteers can operate independently. Subdomains are one way to achieve that, but not the only one. My big worry from the beginning has been, as Jonathan points out, that it will be impossible to create enough trust in the project to persuade people to move their projects to the domains. For example, I'm even nervous about moving SRFI over, and I'm the editor of SRFI.
On the other hand, I do see value in giving Scheme the kind of first-class "home" web site that other languages have. Even if the Scheme community is unlikely to become unified in the way that
Elm's,
Ocaml's,
Python's, and
Rust's community are, it would be great to have an obvious home domain that serves as a jumping-off point for new members and as a common place for reference material for experienced users. There have been some earlier attempts, e.g. the
Community Scheme Wiki and
schemers.org, and it would be great to build on them.
I like the
schemers.org domain. It's been around for forever. It's arranged nicely with links to relevant information (standards, srfis, implementations, projects, etc). It's minimal. It works equally well in a pure text-based browser as it does in the newest beta release bugpack from *insert favourite timewaster here*. It's extremely low maintenance. It's worked in essentially the same way since its inception.
These are many of the same points that I (we?) love about scheme itself.
If it ain't broke, don't fix it.
I'm afraid that
schemers.org is, in fact, broken, and even Shriram Krishnamurthi, who runs it, says so. It's far out of date and rarely updated. We checked with Shriram about changing
scheme.org from redirecting to
schemers.org, which it currently does, to becoming its own site, and he was enthusiastic. But that was months ago, and we need to get working and make something happen.
Instead of focusing on a replacement for something that really doesn't need replacing, why not spend the mental energy on, for example, a discussion regarding if and how sockets could/should be incorporated into the traditional ports paradigm, or if and how a scheme-semi-agnostic FFI would look, or other such matters that could actually affect the future of the language as a whole. Many of the things most requested are the same ones that are most implementation-specific - which leads to greater and greater divergence, and increasingly less chance of coming to future agreement/standardisation.
Please join me at
SRFI to work on all of those things. But there's no reason that we can't do both.