> John's right that it does take more work to change the implementation,
> e.g. to fix errors, when it's in the SRFI document.  That's because my
> rule is that we have to announce changes made to the document itself,
> including fixes, but that fixes to the implementation (outside the
> document) don't require public announcement.  Also, I need to be able to
> reach the author, which clearly won't be a problem in the short term.  I
> hope it won't be a problem in the long term.

Could we create a Git repo that keeps track of the latest bug-fixed
sample implementations for all SRFIs? Then there would be one place
where people could get the latest versions (there'd be no requirement to
announce anything to put bugfixes in that repo - SRFI authors and others
could simply send bug fixes as pull requests to the repo and the SRFI
editor would accept them).

We could also keep the sample implementation in the dedicated Git repo
we currently have for each SRFI document. Maybe the giant repo would be
easier. There'd be one place to keep track of. What do you think?

If the single repo gets too big, 'git subtree' is a surprisingly easy
way to extract subdirectories (there could be one subdir per SRFI) and
merge them back, with full commit history for the relevant commits.