> I like the idea of using hooks except for one thing: I'm reluctant to
> make use of such features of Github because I don't want to be too tied
> to Github.

That's a wise decision for sure.

What I like about these tools that they just do checks and conversions
of the SRFI HTML. Even if these tools break, the HTML can still be
changed manually using normal Git workflows (perhaps temporarily
disabling commit hooks until the tools work again). The conversions will
simply lag behind the new HTML until they are updated.

> That, and the desire to match authors' preferred
> work flows, is why I accept not only pull requests but also complete
> updates and diffs from authors, why the SRFI site hosts ".tgz" files
> containing all the latest files for every SRFI, and why I document all
> pull request activity on the mailing lists.
Sounds like a great service to authors.

Regarding the pull request Git hooks, it wouldn't matter who makes the
PR. The editors could just as well make PRs based on material sent by
authors via other channels. And volunteers could make PRs about XHTML
conversions and possible metadata fixes.

> Despite this restriction, I'm sure there's a way to hook into a CI
> server without actually using Github hooks.

One approach is to have a server poll for changes. This would work well
for checking things that have been pushed to a master branch in GitHub
because the server could just always record the status of the latest master.

The thing is, it's really nice to verify things for each pull request
before merging it into master, and GitHub has an excellent interface for
that. But of course, if push comes to shove, this is a luxury and can be
turned off.

I've normally been using Travis CI to check PRs. But you have to
register each GitHub repo in Travis, which is cumbersome when we have
160 of them. The ideal solution might be serverless, e.g. AWS Lambda.
Unfortunately I don't have any experience with it.