Proposal: Just Use Github

[natefinch]

Before I begin, let me say that I believe that Google and the go team (whatever we may mean by that term) really want Go to be a true open source, community project. My comments herein are intended to shine light on how the current state of Go's development process belies this fact.

There are two common complaints when it comes to the development of Go itself:

1. It's too hard to contribute (this was a whole section of Steve Francia's talk at Golang UK)
2. Go feels like it's a Google-owned-and-controlled project that is not truly "open source"

Both of these are exasperated by the fact that the technical workflow that the Go project uses is significantly different than what has become standard" for much of the open source community. The standard being - use Github. Use GitHub as the primary code storage, use GitHub for issues, use GitHub for PRs, use GitHub for reviews. The reasons for this are twofold - one, they are integrated and closely localized. Two, they're what everyone is already using, so there's zero cognitive overhead. I think most of us can create a PR in our sleep.

18517 talks about accepting PRs... .except that it's not really accepting PRs. It's using PRs as a way to feed code into gerrit. This is going to be a terrible user experience, because it will be disconnected from the normal github workflow. Whatever features Gerrit has over GitHub obviously cannot be translated correctly to github, so the bridge necessarily must be lossy. People will expect to be able to receive comments in a different tab of the same page of their PR... but they will instead have to go to a completely different, disconnected UI on a different domain.

Not only is this a bad user experience, it is yet another signal to potential contributors that they aren't really that welcome. After all, tens of millions of developers use GitHub every day. Projects bigger than Go use GitHub a their main development process in all ways.

Things like The Go project contributing flow is currently configured to work only with Google Accounts. and Our canonical Git repository is located at https://go.googlesource.com/go send not-so-subtle signals that this is a Google project, not really a community project.

The first two lines of the contributing guide are The Go project welcomes all contributors. The process of contributing to the Go project may be different than many projects you are used to.

If the first is true, the second should not be true.

I ran through the contributing workshop at Gophercon 2017. I even had gone through half of it before. I still needed help from one of the guides. It was still arduous. I speak as someone who has written Go professionally 40 hours a week for over 4 years - the contribution workflow deters me from contributing to the Go project. Even after signing up. The fact that it's so different from my everyday workflow just makes the hill to climb too steep.

Other large open source projects seem to do just fine. Look at Kubernetes. It's only 3 years old. And it already has almost 50% more contributors than the language it's written in. It uses GitHub for code reviews, issues, PRs, etc.

In my personal experience, the Juju team at Canonical was approximately 25 full time developers when we switched from using ReviewBoard (which has many of the same features as Gerrit) to GitHub reviews. It was much nicer to have the reviews available in the same page as the PR itself. It was nice that the workflow was the same we used for our side projects. It was nice that contributors didn't have to learn new tools and create new logins on external sites. It was nice not to have to maintain those external systems.

When Google keeps the canonical git repo in googlesource, and uses a google-run gerrit instance for code reviews, it does not make the project feel like it's open source. It makes it feel like it's a google project that they let the rest of us look at from afar, and participate in if we're willing to hike up the mountain.

Let's show the OSS world that Go really is a community-run project. Let's make GitHub the first class citizen that it ought to be in the development workflow for Go. Let's drop the barrier of entry that currently exists even for experienced developers, so that contributing to Go only requires a few clicks through an automated CLA signing process and then normal PRs, reviews, normal git tooling.

[ddatsh]

too hard to contribute, can't agree anymore!

[marwan-at-work]

I've heard on the Gotime podcast and Q&As with the Go Team that Gerrit provides a better experience when it comes to reviewing pull requests.

My question is, what makes a strong argument for Gerrit that Github cannot provide?

[ChimeraCoder]

I ran through the contributing workshop at Gophercon 2017. I even had gone through half of it before. I still needed help from one of the guides. It was still arduous. I speak as someone who has written Go professionally 40 hours a week for over 4 years - the contribution workflow deters me from contributing to the Go project. Even after signing up. The fact that it's so different from my everyday workflow just makes the hill to climb too steep.

I've been writing Go for over five years and contributing in various forms, and I have to say I agree. go-contrib-init makes things better, but the barrier to contributing to Go is a lot higher and with a different workflow from almost any other project that uses Go.

Gerrit does provide a better experience for code review than Github does, though that difference has shrunk over time. At the time Go migrated to Github from Google Code, Github didn't even support split views for diffs! Gerrit still supports a number of things that Github doesn't, but the difference has narrowed significantly. And in my opinion, the opportunity to have more contributors and contributions is enough of a benefit to outweigh the product advantages that Gerrit has when viewed in isolation.

[krisnova]

I couldn't agree with this enough, one of the things I hear most in the wild is how hard it is for people to contribute to Go. As successful as the contributor workshop at Gophercon was, it is an embarrassment to the language that we had to do it at all. Why did we need an entire seminar to teach hundreds of developers who already contribute to many other open source projects how to contribute to Go? I think the avenue in which we interact with the Go source code is hands down the culprit.

If we need concrete data in the guise of experience reports I am happy to provide it.. But honestly I think this issue is probably going to turn out as enough.

[FiloSottile]

I agree that GitHub is closing the feature gap, but Gerrit reviews are still a different experience, which I personally find superior. So I think this should configure as a discussion on the tradeoff between review experience and new contributor experience.

But there seem to be two other sentiments in the proposal which I feel like are unrelated and personally disagree with.

First, that GitHub is "the one true way". I don't take seriously the complaints at the other end of the spectrum like "git was supposed to be decentralized!!!11!" either, but "it's not GitHub" should not be an argument against a workflow per-se, beyond the onboarding inertia, nor does all code need to be hosted on GitHub.

Second, the Google ownership part. Technical infrastructure is IMHO both much less important than people (which the Go team seems to be aware of and working on) and wider than Gerrit. TryBots run on Google infra, releases run on Google infra, the website runs on Google infra. And personally I'm glad the community doesn't have to piece it together.

[arp242]

Back when I hosted my code on BitBucket and mercurial I noticed that people would download my hg repo, make their changes, and then upload it to GitHub, and never sent me a patch.

Obviously not great. So, I moved everything to GitHub. Not because I especially like GitHub, but because git and GitHub have become the de-facto idiomatic tools for open source software development.

I still consider mercurial/BitBucket to be superior – but GitHub is certainly an adequate solution, and using idiomatic solutions is an advantage in and of itself. In that sense it's similar to the Go proverb of "~gofmt~ GitHub is no one's favourite, yet ~gofmt~ GitHub is everyone's favourite".

I would say that the question "is Gerrit better than GitHub reviews?" is the wrong one. The question should be "is Gerrit so much better that we want to skip out potential contributions?"

I don't have to work with these tools daily, so I don't presume to be able to answer that question. We work with GitHub reviews daily at my day job, and while it's certainly not the best system I've worked with, I do find it an adequate system.

[ericlagergren]

We disagreed a bit on Twitter, but I do share your sentiments.

Switching to GitHub means GH is the sole source of truth for Go. This means if anything happens to GitHub—outages, data loss, whatever—or if GH does anything to its product—API limits, changes that break Go's workflow, etc—Go is out of luck. The Go project can avoid those problems if it uses an OSS tool, like Gerrit or GitLab.

Like I mentioned on Twitter, I wonder if the onboarding process could be made smoother if the docs received some TLC. (That doesn't speak to the part of your issue about Google's ownership, however.)

[tylerstillwater]

Agreed. I'd be much more inclined to contribute if not for the contribution process.

One of my previous contributions was closed due to inactivity. I submitted it ages and ages ago, and had no idea it had been reviewed or commented on. After a long time, it was closed cause I didn't respond.

I happily would have responded and finished out the change had I received notification that it had been reviewed. No idea why I didn't get an email or some kind of notification, but I simply threw up my hands at that point. Not worth the rigamarole.

[natefinch]

I don't really think it's worth worry about "what happens if GitHub does X". If that happens, Go can move somewhere else (presuming there's off-GitHub backups, which I didn't even bother to mention because of course there would be). But in reality, github's not going anywhere, and they're not going to do anything to screw up the hen that lays the golden egg.

You might as well say "what if Google goes under?" I mean... they actually have closed down one of their source control hosting services :)

[jimmyfrasche]

The language spec is easier to read than the contribution guidelines

[NuckChorris]

@natefinch I'm not sure if there are tools to backup github issues, but if there aren't, that's yet another reason to switch wholeheartedly to github: the same things which make github better for the Go team will make it better for everybody.

[nasciiboy]

bravo! I wanted to help add support for negative numbers in text/scanner and see the collaboration guide does not invite me to do it

registering a google account on a mandatory way, or accepting a contract to cede code to a project that is already OSS, sucks.

[ianlancetaylor]

As a person who reviews patches, it seems to me that Gerrit continues to provide a much better mechanism for patch review than Github. Even with our current contribution process, there are many many more contributors than there are reviewers.

[ianlancetaylor]

@nasciiboy Whether we use Gerrit or Github, all contributors will be required to sign the CLA to give us rights to distribute the contributed code. That is non-negotiable.

[natefinch]

Yeah, I wasn't assuming the CLA would go away, but hopefully it could be a trivial click through process that could use your GitHub id so you don't have to sign up for anything.

[as]

I speak as someone who has written Go professionally 40 hours a week for over 4 years - the contribution workflow deters me from contributing to the Go project. Even after signing up. The fact that it's so different from my everyday workflow just makes the hill to climb too steep.

I agree completely with this, but at the same time it doesn't feel right to expect the top contributors to tailor the workflow for the rest of the potential contributors. It seems important, at least to me from a quality standpoint, that those who review the most code have the easiest time doing it, as they are the gatekeepers of quality.

I'm not saying it should be harder to contribute to keep contributions away, just that the write-access (or pull access) should not be optimized at the expense of read access (code review, ease of use, etc).

[agnivade]

I myself had kept away from contributing due to this very reason for a very long time. Recently though, I just sat down and forced myself to go through the contributor doc. Hardly took me 15 mins, and then I was up and running ! And this was even before go-contrib-init came out !

Yes, the gerrit workflow is something new, and like anything new, people (including me !) are reluctant to put themselves through the time and energy of learning that. But IMHO, its too small of a learning curve to complain about.

Agree with @ianlancetaylor that Gerrit does provide a better way to review patches.

And like @FiloSottile said, the TryBots do run on Google hardware. If we are talking about moving away from Google completely, I doubt one can run tests on all platforms and with the speed the current TryBots do.

[slrz]

Not relying exclusively on Github doesn't make a project any less community-driven. It simply does not compute.

You make it sound as if Go was some kind of weird outlier when in fact it is very common for bigger open source projects to use Github mostly as a fancy mirror while the primary repo and code review live somewere else.

[purpleidea]

Just drop the CLA entirely. This is corporate nonsense used to make the lawyers feel happy and benefits none of the hackers. Everyone knows that inbound=outbound. #NoCLA

[rakyll]

I'd love to see GitHub doing some improvements to the comment handling. There is currently no way of drafting replies when replying to a code review, or there is no mechanism that counts the addressed and non-addressed issues. It is a major step down if you are reviewing long and complicated patches, the way the Go project often does.

[natefinch]

Please drop talk about the CLA. If you want to propose that, make your own proposal.

On Thu, Sep 21, 2017, 1:03 AM James notifications@github.com wrote:

Just drop the CLA entirely. This is corporate nonsense used to make the lawyers feel happy and benefits none of the hackers. Everyone knows that inbound=outbound. #NoCLA

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/21956#issuecomment-331051660, or mute the thread https://github.com/notifications/unsubscribe-auth/ADCcyH3bMlx3OJHmGYlhzawuK2mS9yTLks5ske4RgaJpZM4Per9v .

[cespare]

@rakyll GitHub fleshed out their review system quite a bit in the past 6 months - 1 year. Pull Request Reviews work such that you can write a bunch of comments as drafts (and edit/delete them) and then send the review as a single batch, like Gerrit. See this and this, for example.

[jimmyfrasche]

I don't care about the CLA or where the main repo is. It's just too hard to contribute.

Gerrit might be nice if you use it all day or even once a month, but, if you look at it maybe once a year, it's a mess.

The rest of it isn't that bad, though the contribution guidelines are hard to skim. It's not bad if you actually read it but if you just open it up with the goal of "to do X I need to do Y", well, buckle in. By the time I figure out what to do I've lost any steam I had to actually do it. Eventually after many months, I'll try again but by then I've forgotten what to do and the cycle repeats.

[rakyll]

@cespare You can only create an initial draft. Responses to the initial comments cannot be drafted. Am I mistaken? I use GitHub PRs for everything else and it is such a chaotic experience even for tiny projects.

[cznic]

This proposal is based on things that I disagree with almost entirely. Moreover, some of them are IMO false.

Several people agreed to the claim that's it's hard to contribute. Yeah, you may have to learn a couple of new things. Maybe you make some mistakes in the first case. Trial and error, less than 30 minutes, I guess, and basically only once and forever. We are programmers, we are used to learn new things every single day of our profesional life - or we are soon out of business. (Good luck to the exceptions.)

TL;DR: I see very little technical ground justifiyng the proposal. Only same strange mix of activism and/or policy making. I am very much against.

[cespare]

@rakyll Yes, I think you're mistaken. You can respond to a PR review by doing your own review which works the same way (except that you can't approve/disapprove your own PR). You do this by responding to a comment with "Start a review" rather than "Add single comment". I think this is only available on the "Files changed" tab, not the "Conversation" tab (not sure why). See pic:

[mattn]

I don't have strong opinion.

Go developer team have to manage issues or pull-requests which is not really issue. For example, complaints, dissatisfaction, biased benchmark results. If PR will be opened, meaning-less PR possibly be sent. I have seen a pull-request where all sources are deleted in other project. Ofcourse, we doesn't want it.

Also since we can do anything on GitHub with only few clicks, there are possibly mistakes that will occur. This can be recovered but it should be carefully. For example, the counting of LGTMs like Gerrit (maybe rakyll mentioned).

I think that using Gerrit still have meaning since gerrit have better way for reviewing. In other thing, I am not a Google believer, but I think, Not to use GitHub may be possible way to raise the contributor's threshold. (Please do not treat this as wrong) This can ignore users who doesn't have development intention that mentioned above.

IMO, I don't think it's not hard to contribute to Go as you think.

[andybons]

This proposal is rather large in scope and the discussion could be more productive if broken out into more specific bits to avoid derailment (talking about the CLA, for example). The primary (and most contentious) issue seems to be that of moving away from Gerrit to use GitHub PRs for code review. I suggest you make this proposal more specific to that issue, because it's the one that a lot of your other sub-proposals hinge on.

I 100% agree that it is more difficult to propose a change to Go than to say, Kubernetes. This experience is something we're trying to improve on and the contributor workshop at GopherCon was a great demonstration of the roadblocks some of our community members run into by using Gerrit and our current tooling. We should do better.

While switching to GitHub would potentially make a contributor's workflow more straightforward, the same cannot be said indefinitely for the reviewers. Switching to GitHub PRs would regress the review experience for many, so the success of this proposal hinges on identifying those regressions and either convincing the maintainers that the corresponding benefits outweigh the sacrifices, and/or coming up with a plan to build tooling to fill in the gaps left by switching.

[dahankzter]

Restricting developers because of a cumbersome process is not good imho. I think anything that makes it easier to contribute is good and this proposal is definitely a step in the right direction.

I wonder if the arguments "You will get used to Gerrit" can't be just as easily applied to Github and it's different review process. Perhaps using Gerrit is more about habit than it being actually better?

[dominikh]

I think anything that makes it easier to contribute is good and this proposal is definitely a step in the right direction.

That statement is easily proven false. Requiring no code review at all would make contributions easier, yet wouldn't be at all a good change.

Perhaps using Gerrit is more about habit than it being actually better?

The various reasons for why Gerrit is a better tool have been presented before, here and in previous threads discussing why Go uses Gerrit instead of GitHub. Furthermore, it cannot be about habit – when the Go issue tracker and code mirror moved to GitHub, Go was using Rietveld, not Gerrit. Using Gerrit instead of GitHub was an active decision, based on arguments that hold true to this day, arguments that this proposal doesn't address. In fact, this proposal is only concerned with making contributions easier for first-time or infrequent contributors, and doesn't take the point of view of reviewers and frequent contributors into consideration at all.

[leepa]

I've worked in some places where we've migrated from GH Pull Requests to Gerrit for the reason that GH Pull Requests (until very very recently) were not ideal for a formal review process. Even with the recent changes, the current PR system in GH does not manage revisions of a changeset well. For example, Gerrit includes the commit message as part of a review which is arguably the most important part of keeping a clean and detailed history.

Larger projects then this are in Gerrit (hello Android) and Gerrit is a well maintained and up to date piece of software. If you know Git well, Gerrit is great. Github hides a lot of things from you. The documentation for Gerrit is likely the issue - I've written a lot of 'Day in the life of' Confluence pages explaining Gerrit to people.

The argument that the process of pushing to a different endpoint is cumbersome? Really? That does seem far-fetched. The setup process for a new contributor has massively improved over time as well. It used to be a lot more difficult.

[ghost]

http://nurmi-labs.blogspot.com/2017/01/patching-ess.html

I recall earlier this year regarding collaborating on a minor patch of ESS, when one of those involved mentioned a Github pull request, the reply from the coder to whom the subject was addressed was that he has an epidermic reaction to such large & centralized entities.

I would prefer if Go would continue to utilise the Gerrit project.

I like the corporate and individual CLAs.

https://golang.org/doc/contribute.html#auth

"Gerrit uses Google Accounts for authentication."

Though I would prefer there were implemented an alternate to the use of Google Accounts for authentication; and, indeed perhaps that information could be hosted on machines outside of the U.S.A., and, in that regard I would suggest the location of Bratislava.

[dahankzter]

That doesn't make it false @dominikh just falsifiable.

If Gerrit is truly better then why isn't it more widespread? It can also be argued that Gerrit is nost as good as the kernels way of using email and patches. Then you can use whatever tool you want to review and thats that so the fact that someone likes ("thinks X is better") something isn't really an indicator other than that that person likes it.

[vdobler]

Please don't do that. Githubs PRs (Bitbucket/Stash being no different) mimick plain git pull request and are simply inferior to Gerrit for what it should be used: Review and discuss a single change. It is just too easy to drop a PR containing all the ugly gore of its creation (the sausage making). The next step after switching to Github PRs will be adoption of gitflow, just because so many people are used to it and it would make their lives so much easier.

I agree that working with Gerrit and the codereview extension would benefit from a bit more documentation which could be more tasks focused. But the contribution process is not really complicated. Its git change and git mail and git sync. (I agree that change and sync and how they interplay with branches should be better documented).

If this is a open source political statement to host Go on Github then please do not mix it with the use of inferior tooling.

[ericlagergren]

@natefinch I hope so! But, that's just the thing—the Go community has zero control over what GH does. Companies host their own repositories for this exact same reason. I think your proposal would do well to think about other OSS code review projects are both easier than Gerrit and that could be used instead of putting all Go's eggs in some corporate basket.

It's not that I have anything against GH or corporations, really, it's just that saying "We must couple our infrastructure and tooling" without considering decoupling them seems a bit... shortsighted to me.

[dahankzter]

Well @vdobler it has always seemed like a tooling issue and then it becomes a matter of taste unless it is actually too slow or simply doesn't work but that is not case here.

I like Github and a lot of stellar developers and projects use nothing but Github so it is not about skill or competence but simply of taste. Thats my opinion at least.

[ghost]

Coding exercises (for fans of hg and git).

http://wiki.9front.org/bounties

fully functional, read/write hgfs

fully functional, read/write gitfs

[kjk]

@vdobler If you think that gerrit is so great, why are you allowing GitHub PRs for your own projects like https://github.com/vdobler/ht and https://github.com/vdobler/chart ?

We want to use GitHub PRs for exactly the same practical reason that you accept GitHub PRs for your projects: every potential contributor already knows how to use GitHub for making contributions to GitHub projects.

I'm pretty sure if you were to tell people they have to read a contribution guide and use unfamiliar tooling, you would get zero contributions to your projects.

Go is significant enough to get contributions despite arduous contribution process but it certainly turns away significant number of potential contributors, myself included.

I applaud that Go team recognizes that as an issue but if attempted solution is unscalable in-person tutoring that achieves worse results than bigger, more active projects (Swift, Tensorflow, Visual Studio Code, TypeScript, .NET to name just a few) then maybe it's time to ponder why Apple, Microsoft and even other Google employees are capable to be productive using GitHub UI for reviews AND make contributing easy.

There are thousands of projects on GitHub, quite a few bigger than Go, yet as far as I know Go is the only one that insists on this semi-hosting on GitHub and insisting on using separate tooling for submitting contributions.

[rogpeppe]

Even with the recent changes, the current PR system in GH does not manage revisions of a changeset well.

I'd like to explicitly reiterate this. I review large PRs all the time. They often have multiple updates over a significant period of time as a PR iterates towards acceptance. In github, when rebase workflow is used (almost universal) I cannot see the difference between different updates. That is, if I ask for some changes to be made, I cannot see whether those changes have if fact been made. This is crucial! Without this feature, reviewing takes longer and is more error prone.

Even if the submitter remembers to avoid rebasing before submitting an update, the changes are still lost when the branch is rebased when the PR is accepted. When diagnosing problems, it is incredibly useful when I can go back in time and see the full history of a given commit. Github does not make that possible. This for me is the main reason that I don't believe Go should move to using pure github reviews.

[dahankzter]

Are the changes that led up to a particular change set really that important @rogpeppe ? I understand it can be valuable in some instances but isn't the resulting change set what matters and even what should be reviewed? The fact that it took a hundred steps or just a few is not that relevant right? Perhaps I am simplifying it a bit but when I look at source history I prefer atomic meaningful changes that are free of tiny nitpicking "fix" commits.

[typeless]

There are already some third-party plugins for code review like reviewable.io. If Gerrit can be integrated nicely like reviewable.io, then not only the Go team can still have the best experience, other projects on Github can benefit from it as well.

[dsnet]

Are the changes that led up to a particular change set really that important @rogpeppe ?

Absolutely. I regularly go through the code history and read discussions on changes (sometimes from years ago!) in order to understand why something is the way it is today. On Gerrit, it's fairly easy to follow. GitHub's PR review system makes it really hard for me to follow the discussion that occurs on a PR after the fact. I'm speaking as someone who uses both Gerrit and GitHub's review system.

[dahankzter]

Point taken @dsnet I get that going through the discussions can be very helpful to understand why something is the way it is. I don't think Gerrits upper hand outweighs the easy of contribution though.

[mvdan]

Is there an ongoing effort to get GitHub to add some of these important features, such as PR revision tracking? I would be in favor of this proposal if it was coupled with reducing the pain that changing to GitHub would have on reviewers and maintainers.

If the intent is to switch to GitHub as it is today, I lean against the switch. As others have pointed out, the number of reviewers is relatively small and the quality of reviews would drop, given that the tool is just not as powerful.

[bnjjj]

+1000 Use usual workflow with github = really open source and a lot more contributers

[gbbr]

While I do agree that GitHub has improved a lot and that the PR system has become better (and more closely aligned to that of Gerrit), I think that @dsnet clearly makes a strong point here about GitHub making it difficult to follow history. Until then, Gerrit holds the upper hand.

While I would like to have GitHub used for the sake of simplicity in the process, I think that switching at this point would have the opposite effect. In my opinion using Gerrit does not make the project less community-run. Everybody is welcomed to contribute.

Additionally, as far as I know, Gerrit stores all the review data in a ref on the project (refs/changes/*, refs/review/*, etc). This can be fetched if you ever wish to move the repository without losing history. GitHub on the other hand owns all your PR data and I personally don't know of an easy way to extract it (although there are some backup tools).

[leepa]

Is there an ongoing effort to get GitHub to add some of these important features, such as PR revision tracking?

Whenever I've asked on this topic - GitHub is really cagey about what they do in this area. They run a very opinionated shop (which is good, it made them the success they are!) but the result is feedback seems rarely listened to. In fact recently had a run in with their sales drones who were claiming that our Org. didn't own the rights to our repositories (I kid you not!)

There are already some third-party plugins for code review like reviewable.io. If Gerrit can be integrated nicely like reviewable.io, then not only the Go team can still have the best experience, other projects on Github can benefit from it as well.

Replacing one external tool with another doesn't seem like the right fix for anyone.

[griesemer]

As a day zero Go contributor I appreciate efforts that make contributions easier for everybody. But we don't just want any contribution, we want high-quality contributions. "Open-source" is not a quality seal per se. Thorough code reviews are a primary mechanism to raise and maintain high quality, and thus the code review tool is of primary importance. The selection of Gerrit was a deliberate choice. In fact we would much prefer much more sophisticated code review tools (and we use one inside Google). I think any move to a different system (incl. just Github) would have to provide at least as good a code review experience or better.

[DmitriyMV]

In fact recently had a run in with their sales drones who were claiming that our Org. didn't own the rights to our repositories (I kid you not!)

That sounds troubling.

As it stands - for me, even being an external observer, reviews for the complex patches like ticker per goroutine and GC patches are a must. Gerrit is just that better at following the "train of thought" in such code review.

[rogpeppe]

FWIW I think that small code reviews would be just fine with pure github. I'm thinking things like typo correction, adding examples, fixing doc comments. It's hard to know where the line should be drawn though.