> Setting up this mailing list is a great step, but we'll need to do
> something else to plan and coordinate people's efforts.  Should we use a
> document in the Schemeorg Github repo <https://github.com/schemeorg/> to
> keep track of to-do items, e.g. who's working on what domains and what
> tasks are being worked on for each domain?
>
> For SRFI, I always steer people away from using Github's issue tracker,
> etc. because we want to be able to keep a record of all the discussion
> about each SRFI.  I don't have strong feelings against doing that for
> this project, though.  There are also in-repo issue trackers that we
> might consider, e.g.git-bug <https://github.com/MichaelMure/git-bug>.
>
> In any case, having a central place to coordinate our efforts seems
> essential.

IMHO we should treat each subdomain as a separate, autonomous project
from the start. That's a good habit if we want to keep the governance
model simple over the long term.

As things stand:

- All data for doc.scheme.org and api.scheme.org is under the
<https://github.com/schemedoc> organization, and we've been using those
repos' issue trackers as well as the xxxxxx@srfi.schemers.org mailing
list for discussion.

- Likewise comm.scheme.org, persist.scheme.org, test.scheme.org,
web.scheme.org all have their own GitHub organizations, as well as
mailing lists linked from the page
<https://srfi.schemers.org/srfi-list-subscribe.html>.

- All data for registry.scheme.org is in one repo
<https://github.com/schemeorg/registry.scheme.org>, and the
xxxxxx@srfi.schemers.org mailing list is used for discussion.

In practice, these arrangements have worked reasonably well so far.

I'd recommend not enabling the issue tracker in the
<https://github.com/schemeorg/schemeorg> repo which hosts the DNS and
www.scheme.org frontpage stuff. This is the most important repo, so for
maximum transparency and platform neutrality, let's use this mailing
list to discuss changes concerning the DNS and the whole domain.

> I'll contribute an item for myself:
>
>   * I'm slowly but surely going through every SRFI, collecting
>     signatures for all macros and procedures in a file of
>     S-expressions.  My intention is to build an index of SRFIs.  I hope
>     others will contribute indexes of R6RS, R7RS, Snow, etc.

This is excellent, and should probably be integrated into the doc project.