Thank you for the continued interest and suggestions :)

>> Is it possible to setup Continuous Integration at http://travis-ci.com/ for SRFI repositories or another service that possibly support windows and other platforms. As far as know there is no service offering free CI for windows platform. I read there is an experimental CI server at https://github.com/srfi-explorations/srfi-server maybe we can use that already?

It's definitely possible, and not a huge amount of work; more below. But
last time we discussed it, Arthur preferred to start by keeping things
as simple as possible (i.e. only a command line program we can run on
our own computers to validate/extract metadata from SRFIs) and then
perhaps do further experiments from there. He has a good point, as it's
most important to protect the continuity of the SRFI process and
anything else is a nice bonus.

>> Is it possible to include a markdown file in the SRFI repository that will be translated to html by pandoc

>> Is it possible to include a simple Makefile that will allow:
>>
>> Translate markdown to html via pandoc

I'll defer to Arthur here.

>> Run SRFI tests against various scheme implementations

This would be great, but I got the impression that Arthur would like to
move SRFI implementations (except the reference implementation) away
from the SRFI repos themselves, into the repos of each Scheme
implementation. (Please correct me if I have misunderstood this.)

> Whatever is planned, I think it is very important to choose
> technologies that are not tied to GitHub but that work with other Git
> providers at least as well. GitHub is not free software, and we don't
> want to have a vendor lock-in.

No worries, everyone involved agrees about this. We want to retain the
ability to move away from GitHub.

That experimental server uses the following things from GitHub:

1. GitHub sends a HTTP POST to the server whenever  a commit has been
made to one of the SRFI repos.

2. To implement status checks for pull requests, GitHub can send
(extremely simple) HTTP POST notifications to the server, and in
response, the server can HTTP POST a status back to GitHub to add a
status to that PR. This isn't currently implemented but could be with a
little effort (an OAuth key is needed to post a status to GitHub).

3. GitHub offers a URL syntax to download a given git commit (currently
always the latest commit in the master branch) from a repo as a zip file
(a tar file would do just as well).

All of these things are quite simple and are probably available in
BitBucket and GitLab also.

Anyway, we want to design the process so that any CI server is an
optional part of the infrastructure. So that if the server fails, the
only thing we lose is a little convenience, but the main SRFI work can
still go on as it always has.

Also we considered using Travis CI at one point but that's probably
somewhat difficult to setup since we have so many repos (i.e. each SRFI
has its own). There were rumors that Travis may be bought and shut down
at some point, but like GitHub, the services offered by Travis are very
simple and standard and could probably be quite easily implemented on
top of most other CI services. We're not doing anything very advanced.

> I looked at the archive https://srfi-email.schemers.org/srfi-discuss/ but could not find any discussion related to this.
There were a few messages discussing Continuous Integration at length,
but unfortunately they are buried somewhere in one of those mega-threads :)