We now mirror GitHub PRs into Gerrit. Gerrit is still our upstream Git server. Gerrit is still where we do reviews and press the "Merge" button. (And once merged, it gets mirrored back to GitHub)
But now we have a bot that slurps PRs into Gerrit and syncs comments back and forth and closes PRs when needed. (We'll do more fine-grained comment sync in the future. We just shipped an "MVP" for the Go 1.11 tree opening).
Some more information is at https://golang.org/wiki/GerritBot
Code is at https://github.com/golang/build/blob/master/cmd/gerritbot/ge...
Clarifying that I believe that my personal off work time is valuable to myself. The more time and friction I have to spend putting in a pull request/code review is the less time I get to myself.
I've basically given up on fighting with the WMF's Gerrit install and outsource the work to other people. I push a commit up to a github repository, open a task, and ask another developer to grab my commit from a new git remote. I want to write code, not wrangle with whatever Gerrit wants me to do to submit code. And then look for tiny links on a cluttered page. No thanks.
I now just avoid it whenever possible, usually forking my own thing, and just doing what I need.
One example of a use-case where GitHub falls short is offline support: you can't take the issue tracker and wiki with you. There are alternative tools such as fossil  which have built-in bug tracking and wiki, which is an attractive feature for some people.
Hopefully gitlab or bitbucket comes up with a solution which enables the owners of the repos to move bugs/issue tracking, which will force github to enable this feature as well.
I like fossil because it's all built-in and can be wrapped up in a single file. But it's always great to have more choices available.
For example, now we have github, gitlab, mercuirial(bitbucket).. I only use the above 3.. but I am sure I can come up with 100 different github/gitlab type companies.
When there is so much fragmentation, it becomes difficult to find project or code reliably. For example, I have seen certain projects on bitbucket, which are awesome (say `ProjectA`) and create a lot of value. But there exists a very similar but differnt project `ProjectB` on github. Probably the author of `ProjectB` had the same problem that the author of `ProjectA` had, but couldnt discover that `ProjectA` already exists.
What open-source software enables you to do is to reuse software, however, if we create so many distinct places where the code resides, it becomes harder and harder to discover that code. Which leads to recreating codebases over and over again.
thanks for pointing out fossil by the way..
Off-topic, but I'm genuinely curious why you chose this capitalization?
(OpenStack Swift, that is, not Apple Swift. And not Suzuki Swift either.)
I have first hand information from two projects (one of them large) that contribution, apart from drive-by doc fixes, does not increase.
Meaningful contribution decreases, because existing devs leave or become inactive because of GitHub.
A lot of projects moving to GitHub are in the Gervais-principle stage.
For security, mostly. Our isolation is good but not perfect.
We could probably do a smaller set of (secure) builders for all patches, but it hasn't been a priority.
I'm really only a dabbler in Golang, so would appreciate any context.
For instance I was affected by the recent go-bindata owner change. The Github user deleted their account and some random user reregistered the original user's name and recreated the repo (albeit seemingly innocently to help everyone get their CIs running again).
Actually while we're on the subject, Golang's whole package management experience is surprisingly disappointing :/
OG gophers vendor their deps into their repo and avoid creating dependencies on 3rd party code whenever possible. The Go stdlib is very full featured so it is not unrealistic.
The problem with the go-bindata could be avoided by always vendoring/forking your deps and never trust any VCS provider (e.g. GitHub, Bitbucket, source forge) to handle your critical dependency needs.
The Gopkg.toml/Gopkg.lock files in dep are quite similar to Rust's Cargo.toml/Cargo.lock files. I think it's a good move as Rust has probably the best package management story out there.
Also, as the other comment mentioned, github.com is not "special" in any way. Any website with a git repo will work just as well. In fact, some key libraries are served from golang.org/x/<whatever> not github.com.
Anyone who vendored, or at worst kept a local copies of their dependencies littered all over their machine somewhere would have been fine.
You won't see a PR from me. I'm happily ensconced in the JVM (Java, Kotlin) and Rust land these days with the occasional foray into Python here and there.
Hopefully they can do something about getting rid of Google groups now. It's an extraordinarily poor organ of record. The low-friction Github issue tracker is full to bursting with high-ranking results for things that amount to support requests, but the pat response is a slightly-too-curt "ask this on golang-nuts, closed, kthxbye", and that's where the trail ends.