too hard to contribute, can't agree anymore!

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?

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.

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.

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.

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.

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.)

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.

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 :)

The language spec is easier to read than the contribution guidelines

@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.

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.

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.

@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.

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.

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).

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.

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.

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

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.

@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.

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.

@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.

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.

@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:

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.

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.

I've filed #21983 for a possible way to improve the contribution guidelines in the meantime based on issues I've had with my aborted attempts at the process

FWIW, @dlsniper, yes, that has come up in the past: https://twitter.com/bradfitz/status/692510984339111936. :-)

I wanted to chime in here, not because I necessarily have something to add, but to add an interesting perspective and experience from two contributors.

I used to frequent the Gophers Slack channel, so I could help people ad hoc. I met @zmb3 because he had asked for help with the “git-code-review” tool after it put him in a weird state. After working with @zmb3 for awhile to get him unstuck, he got me an interview with his company and ultimately I got a job.

My point is the process is so poor/complicated/convoluted/, less so now, for contributors, being able to help someone get unstuck got me a job because it’s a black magic process. I have made a couple small contributions in my several years of professional Go experience, and I decided I didn’t want to keep contributing because the process was complicated.

I get that cherry-picking is super helpful, but as half the Golang build infrastructure does various git operations anyways, a merge workflow with cherry-picking would be easy to add.

https://gerrit.googlesource.com/summit/2017/+/master/index.md

Gerrit User Summit 2017
30 Sept. through 3 Oct.

CodeNode, 10 South Place,
London, EC2M 7EB, GB

http://www.varastokirjasto.fi/digiphpt/dump_fnatur.txt
"28 Skogen och vår identitet Erkki Lähde";;"1984"

'The Forest and our Identity'

Prof. Lähde recounts when as a young graduate out of forestry studies, he had the occasion to visit a village in the Finnish countryside. He noticed in the area a group of trees which to his view was overdue to be cut. But enquiring upon the local villagers of that stand of trees, the reply was that there was an old woman from the village who had liked to walk among that grove. Thus the trees were saved out of piety.

Erik Erikson, a Norwegian pædagog had introduced me to his writings, wrote once of how moralistic man and rationalizing man, as an emotional and political being undoes with "compulsions and impulses what his thought has invented and what his hands have built".

There's also a Viennese saying:

"Es pressiert nicht. Wir haben Zeit."

So, a valid question for me:

Is there an æsthetic in the workflow of those using Gerrit?

It is important to understand the level of effort it takes for maintainers to review so many changes. Github does not make that easy for projects with a high volume of "pull requests". Gerrit helps maintainers tune in and accept changes. Github is just a UI!

Each commit should be laser-focused on a particular issue and include Release Notes suitable for user consumption. There is no excuse for sloppy, mangled pushes.

I read through this thread, and I find it interesting that the other of the two complaints brought up in the OP is the one I feel is the legitimate issue, yet it got practically no attention:

Go feels like it's a Google-owned-and-controlled project that is not truly "open source"

But before I get to that, I will briefly comment with regard to GitHub vs Gerrit and "ease of contributing". If Gerrit is complicated or unfamiliar, then it seems the most productive plan of action is to report issues to the Gerrit project or even contribute improvements directly. You're much more likely to effect change in Gerrit (or a similar open source tool) than others will have in convincing GitHub to add the various features it lacks for reviews, among other things.

Additionally, if the Go team were up for changing the system, I would personally push for using git format-patch/send-email, which is used by the Linux kernel as well as countless other long-running open source projects (or if they don't use Git, they still use a mailing list system). I'd propose it mainly because, aside from those commands being included in Git and the workflow arguably being even easier than Gerrit (it's just email!), it would still offer some semblance of the functionality Gerrit offers, but it would also create a little mayhem, too--and who doesn't enjoy that every now and then? :)

Now, back to that second point. Go is a "Google-owned-and-controlled project". That CLA you sign? It assigns the copyright grants a license for your contributions to Google. I'm not about to claim that the CLA is much of an issue, though. Go can be Google-owned and still be an open source project. There are other symptoms that could be looked at instead, in my opinion.

Quite a few times I've either read or taken part in discussions that included one of the Go team members mentioning a topic as having been discussed by the Go team in one of their internal meetings, sometimes not expanding beyond that. Similarly, I feel like the team's resistance to shortening the 6-month release cycles to approach a more continuous-delivery-style pipeline might be evidence that the team is sort of siloed by Google's internal mechanisms and culture. If you're going to make the argument that Go doesn't feel like a true "open-source" project, these would be some of the things I would want to discuss.

I do not like where this thread is going.

An increasing number of comments are stating or implying that contributors not willing to put in the effort to overcome the inertia are somehow worth less. @Manishearth articulated well why it's wrong in #21956 (comment), but I want to go a step further and say that it's unacceptable.

While I fall on the side of optimizing for review myself, that's about process and resources, not people, and any lost contributor is an unfortunate trade-off which we should try to compensate for (which as @rsc reiterated is the point of #18517). Can't believe this had to be said.

(In case this sounded official, this is a personal opinion and I have no affiliations.)

(it's just email!)

It's not. Lots of folks don't realize this, but git-send-email is a really hard workflow.

It works great if you already use a local mail client. Many don't. Many can't, because of port blocking and firewalls (a large fraction of universities do this for example). Port blocking SMTP in particular is annoyingly common because of the way spam detection works. If you are behind a large NAT (like a university, or a workplace), and you use the connection to send out lots of spam directly via SMTP, it's very easy for that IP address to get banned. The administrators may not want to deal with this, so they'll just block the port.

The traditional patch mailing list approach also has terrible UX even with git-send-email. Replying to a mail requires copying the message id and a bunch of nontrivial steps which are definitely not built in. It's possible to set up local mail clients to work well with this, but this is not the default behavior.

The obvious way out here is for folks to "just" use web based clients with git format-patch, but that doesn't work well either. For example, GMail converts tabs to spaces (or was it the reverse?) in plaintext emails, so you can't just paste git format-patch output there.

It's possible to build tooling that makes all this pleasant (I'd love for this to exist!), but it doesn't exist right now as far as I know. I would be wary of moving to a patch mailing list approach for reasons that it is simpler (it has its merits! this isn't one of them)

That CLA you sign? It assigns the copyright for your contributions to Google.

No, it's a copyright license, not a copyright assignment (read the full text). All contributors still retain full ownership of everything they contribute to this or any other Google open source project. This is orthogonal to the topics actually discussed in this issue, but I wanted to correct any misunderstanding on this point.

@willnorris - You're correct! Sorry, I got the terminology mixed up. It's late here. :)

OK, biased comment stricken. You've all got a good point. Maintainers also have to deal with all of this daily and some may be unpaid volunteers. In a perfect world Gerrit would have a GitHub integration plugin, IMO.

A few months ago I was invited to join a panel on contributing to Go organised by Ashely McNamara.

During that panel I asked the audience, via a show of hands, "who felt that contributing to Go implies landing a commit on github.com/golang/go?".

Nobody raised their hands.

I mention this to suggest that contributing to Go is not limited to landing code in one specific repository. Aside from non code contributions like running workshops, meetups, user groups, conferences, and release parties, the majority of code written in Go (which is what I see as contributing to Go) will be in repositories outside github.com/golang/go (or its sister sub repositories), and this is how it should be.

Do people feel that they cannot contribute to Java because it is hard to submit a contribution to OpenJDK (which as I understand it has a highly cumbersome governance model)? Of course not; they contribute to products built on top of the JDK.

The notion that you are not a real or valued Go developer until you have contributed to the stdlib is toxic. This is the real problem.

self-hosted GitLab or gitlab.com is a better open choice IMO

I love GitLab, but GitLab.com is very unstable. Hosted GitLab CE would be cool, but I fail to see how that's not a lateral move. In my PoV, there's nothing wrong with Gerrit, there's just some potential gain for GitHub due to the sheer size of the open source community on GitHub.

For a project such as Go, the key issue barely discussed here is the sheer amount of infrastructure built on it. Docker, which is Go based, now runs infrastructure for major corporations and even countries. Much of Bitcoin, Kubernetes, CloudFlare, etc. heavily use Go. When a project serves as the base for that much, the process for making changes needs to be very nitpicky so as not to break major systems.

Linux is another open source project. It uses GitHub as a mirror, has a more complex contribution process, and is even more strict. It runs the majority of servers, so they need a very fine control over it.

Gerrit gives the reviewers more control and increases the efficiency. Yes, it may require more hoops than you may be used to. Yet Go is now mission critical to many just as Linux, Apache HTTPd, nginx, Docker, Python, MySQL are. At this point bugs and idiosyncrasies in the language are now features in active daily use. Making a small change could have an effect similar to pulling the left-pad package off of npm. Thus the process of contributing needs to be thorough, even if the extra testing and hoops seem redundant or unneeded.

https://talks.godoc.org/github.com/go-hep/talks/2017/2017-08-24-go-hep-acat/talk.slide#1

A circa 2017 printing on Go and HEP.

@Manishearth

(it's just email!)

[git-send-email] works great if you already use a local mail client.
Many don't. Many can't, because of port blocking and firewalls (a
large fraction of universities do this for example). Port blocking
SMTP in particular is annoyingly common because of the way spam
detection works. If you are behind a large NAT (like a university,
or a workplace), and you use the connection to send out lots of
spam directly via SMTP, it's very easy for that IP address to get
banned. The administrators may not want to deal with this, so they'll
just block the port.

This is not how git-send-email works. People DO NOT send
SMTP from their own machines. People using git-send-email USE
other SMTP servers just like people using any other mail client,
including Outlook or even Gmail on their phones. In fact, the
git-send-email literaly lists using Gmail for SMTP as an example.

Github us not git, anymore that Sourcefirge was CVS or SVN. The idea that GitHub is the one true place to put code is ridiculous and short sighted.
The Gerrit flow is quite pleasant. I don't think there's any harm in exposing people to something a bit different.

I think everyone has made their positions clear on this issue.

I think we have two plans: one is to tackle issue #18517 to add a flow between Github pull requests and Gerrit, and the other is to clearly document what seems to be lacking in the Github review flow as suggested in #21956 (comment) . I have created a new issue for the latter at #22002.

This issue is too large and diverse to usefully tackle either of those proposals, so I am going to close this issue. Thanks for everyone's input.

People using git-send-email USE other SMTP servers just like people using any other mail client

@4ad which also goes through various ports (including 25) which are often blocked.

Because port 25 isn't meant for client to MTA communication, port 587 is. And no respectable ISP blocks port 587.

Many universities follow a whitelist, not a blacklist approach.

I've dealt with this problem with students I've mentored in open source more times than I can count.

(anyway, this is getting off topic)

Many universities follow a whitelist, not a blacklist approach.

Literally every university in the world sends e-mail. Except perhaps universities from North Korea. If you can send e-mail, you can use git-send-email.

As this is both offtopic for this discussion, and also as this issue has been closed, I ask you to stop.

Both of these are exasperated by the fact that...

@natefinch exacerbated