> GitLab's worst incident I know of is when they lost customer data due
> to every single backup they were using failing.  They simply didn't
> bother to check if any of them were working, not even looking at how
> much data was being stored in an S3 bucket.
>
> There tend to be consequences for paying below market rates as they're
> strongly reputed to do.  100% remote also takes management talent
> that's generally not in evidence in our field.

That's pretty bad for a company of that size. Shows that we should have
backups of everything. It's good that you're on the case.

> One other reason to make it the master is that I'm pretty sure a
> lot more people have GitHub accounts than GitLab ones, and if both,
> use the former a lot more, if not all but exclusively.

True. We have an interminable, minor GitHub vs GitLab vs others vs
private server tug-of-war in the Scheme community :)

> I've suggested that pull request discussions happen in the comments
> on the pull request, and get scraped and sent as one digest to
> the mailing list after resolution.  That way we can limit traffic
> on the mailing list, by announcing when a pull request has been
> made and providing a link, so those interested in the specific topic
> can subscribe, and the rest aren't bothered.

Sounds reasonable to do preparatory work where it suits people as long
as decisions are made on the mailing list.

PRs cannot be disabled in GitHub. I think they can be in GitLab.

> ssh.srfirsync.net "git clone git://github.com/scheme-requests-for-implementation/srfi-$i.git srfi/github/srfi-$i.git"

OK, that is very easy!

For subsequent ones do you need to replace the clone with pull?