> A GitHub link is straightforward.

In fact there's already a GitHub link on each landing page (e.g.
<https://srfi.schemers.org/srfi-168/>) but it took me some time to
realize that. It's also faster to navigate when reading SRFIs if there's
a link in the document itself as well.

> Shell scripts and lists of implementations belong in the repo, because they
> change over time.

The "srfi-nnn.html" file is in the repo, so it can change as easily as
the sample implementation. (If the change is trivial, e.g. adding a new
implementation to the list of tested ones, a new draft of the SRFI
probably doesn't need to be announced, or what does Arthur say?)

IMHO it's really useful to have the list of tested implementations in
the SRFI text itself. That way it's faster to get an impression of what
has been tested where when multiple SRFIs have interdependencies.

> We used to provide a tarball, but it was impossible to keep up to date
> (indeed, many of the repos for old SRFIs started life as tarballs).  Stick
> to the repo.

Easy to imagine. GitHub archive links provide the best of both worlds,
though the GitHub UI has a those same download links in a standard
location so maybe that's good enough. Less clutter in the SRFI text.