> Thanks for the update.  I'm impressed!  Thanks for the detailed
> explanation of how it works, too.

Glad to hear that :)

I didn't implement the pull request checks yet because I wanted to get
some feedback first but I believe they can also be done with just that
one organization hook using GitHub's OAuth API. So there shouldn't be a
need to configure hooks for each repo separately -- a huge relief.

Also those "info.scm" metadata files are missing most of the stuff that
my Python script was able to extract (e.g. SRFI status and revision
history). I didn't port it over to Scheme yet but it's just a matter of
putting in the work. The "args.scm" files contain almost all the stuff
the Python code extracted.

I can implement all that extra stuff but I'd like to get the go-ahead
first. It's becoming a sizeable project so it's be nice to avoid wasted
work. At the moment I don't think any other workflow is viable compared
to this because the tools are written in Scheme, the GitHub integration
and Heroku web hosting are easy and free, and having the CI server be a
web server means we accidentally made an SRFI API with no extra effort.

And if there's a problem with the CI server, all you need to do is
disable the webhook in one place in GitHub. Then the process can go on
manually just like it has until now. I don't see any easier alternative.

> It looks like a lot of manual work is still required to make the HTML
> acceptable to the tools, e.g. your changes here:
>
> https://github.com/srfi-explorations/srfi-1/commits/master
>
> Based on your explorations so far, how much time do you think will
> typically be required to prepare one SRFI?

The HTML classes are the same ones I had before, so I'd guess it's about
10-30 minutes per SRFI. I'm waiting for Ciprian to finish the XHTML idea
he had, to evaluate if we could use that instead (for the final HTML
structure that the metadata is extracted from -- not as a requirement
for SRFI authors). For the CI server, the S-expressions and the GitHub
workflow, it doesn't matter what kind of HTML we use. It should be quite
easy to adapt those to consume whatever we come up with.