It's unfortunate that it isn't possible to disable pull requests. There is already noise appearing there, which will always be a wart so long as pull requests can't be disabled.

Noise? That's how contributions are called now?

No, it's just that the Go team have decided to continue with their current contribution process rather than using pull requests. I don't know whether this is a permanent decision or not.

"The Go team will not be accepting pull-requests here. Contributions must still go through the normal code-review process and gerrit. The updated contribution steps are not yet available though."

https://github.com/golang/go/pull/9219

This is something very similar to that is being planned for FreeBSD repositories on GitHub: automated process turning pull requests into FreeBSD's Bugzilla bug reports and a comment closing the pull request, informing user about the Bugzilla bug link and how to proceed.

Go already has an established contributing process, and people who make PRs without bothering to understand that process are likely just making noise.

In that case why are they using GitHub?

Linux is on Github as well (https://github.com/torvalds/linux) , and probably like Linus, some people don't like the Pull-request method for dealing with contributions.

Linux is on https://git.kernel.org/cgit/ .

GitHub provides the best web-based git repository browser, as well as various other useful features. The only other reasonable alternative for a large open-source project, aside from self-hosting, is bitbucket.

I would like to disagree with the "the best". Mostly because it's obviously your opinion and not something you can say definitely.

Can you give any alternatives?

I disagree. GitHub looks cluttered and the contrast is too low for speed reading. I prefer the hg interface, for example:

https://hg.python.org/cpython/

Another interface I prefer is:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/

GitHub provides the best web-based git repository browser

I like Bitbucket's side-by-side diff view so much, that I think I prefer Bitbucker for browsing.

But this is only because Bitbucket has the side-by-side diff view, anf GitHub does not.

GitHub introduced side-by-side diffs recently.

Is their contributing process described in README or in some other file within the repo?

There is, but since we're only partway through migrating to git/github, the README still shows the old instructions. The new contribution instructions will appear here in the next few days: http://golang.org/doc/contribute.html

Not that it really matters, right now, as we're in a pre-release freeze.

Make sure there is a CONTRIBUTING.md file in the repo and Github will automatically highlight it to be read when someone opens a PR

I've seen projects solve this problem by keeping a pull request open that indicates where contributions should go instead.

This was announced in mid November: https://groups.google.com/d/topic/golang-dev/sckirqOWepg/dis...

To be clear, Go is not "on" GitHub except for its issue tracker and wiki. The code is being developed, reviewed and submitted on https://go.googlesource.com, using similar infrastructure to Android and Chromium.

So, that c/go code I see in the repository isn't actual code or...?

Its actually pretty cool that all the google code issues got turned GitHub issues, in the same exact order as the google code issues such that the issues numbers are still consistent on Github.

I'm guessing they did it with an import script - something like http://www.iqandreas.com/github-issues-import/configuration/...

I'm getting 404, has it been removed?

Did anyone do anything special to get their contributions attributed to their GitHub account? Mine are not showing up here: https://github.com/golang/go/graphs/contributors

Do you have the mail address you used for your contribution in the set of github email addresses? (https://github.com/settings/emails)

Just added it now, perhaps it will update. I'll check back on it later, thanks.

I think it's because of the distinction of Author and Committer. I also don't see my name there: https://github.com/golang/tools/commits/master/cmd/cover/fun...

No, it's because the page only tracks the top 100 contributors, the cutoff is currently 6 commits.

For instance "spaolacci" is #86 with 8 commits, he's only ever been an author not a committer: https://github.com/golang/go/commits?author=spaolacci

I'm not sure about that either, I have 32 commits:

➜ go hg log --user "Shawn Smith" | grep user | wc -l

32

Edit: I'm there now. Not sure what fixed it, starring the repo or adding my email address to GitHub.

See https://help.github.com/articles/why-are-my-contributions-no....

The most likely reasons are:

  - your email address used for your Go contribution is not associated with your GitHub account
  - your contribution is over a year old
  - you haven't starred the project

Did someone else notice the c joke (?) in the first 3-4 commits?

https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfae... https://github.com/golang/go/commit/0bb0b61d6a85b2a1a33dcbc4... https://github.com/golang/go/commit/0744ac969119db8a0ad32539... https://github.com/golang/go/commit/d82b11e4a46307f1f1415024...

So these are actually commits from the C language? Or are they spoofed?

Obviously there wasn't Git back then, but did they use some sort of version control when developing C?

Unfortunately, this joke makes GitHub Graphs page much less useful, because graphs start from 1972.

https://github.com/golang/go/graphs/contributors

Is there a way to get this fixed?

How come the number of issues is that high ?

I find it interesting that Rust has a lot more contributors compared to Go. Comparing https://github.com/golang/go and https://github.com/rust-lang/rust, all contributors: 380 vs 695, contributors with more than 100 commits: 17 vs 35.

Keep in mind that contributing to Go requires that you sign a contributor license agreement, something people might not want to go through (no pun intended) for small changes.

BUT this allows for easier changing of the licensing.

That's a "feature"? (from a contributor perspective)

I believe Rust requires a CLA as well. Might be wrong, but I seem to remember getting a mail about that a while back. A rust dev that knows for sure can correct me, if necessary.

Rust does not require a CLA.

Not quite right. "Those with review privileges or direct push access are required to file a Mozilla "committer agreement". "

(FWIW: From a legal standpoint, this doesn't make any sense. Either all-in or all-out makes sense. There is no legal distinction to be drawn that the above captures, AFAIK)

See the committer agreement section 4, which covers this case: https://static.mozilla.com/foundation/documents/commit-acces...

All code committed to the Rust repository goes through someone who has signed a CLA, including this section.

Rust uses the same policies here as Firefox.

So does this mean all original code (IE not third party code) requires a CLA?

Or not?

If so, then Rust requires CLAs. Great, legally sound.

If not, this makes no legal sense. Simply having people with a CLA commit it buys you nothing, legally :)

As I said, all-in and all-out policies make sense. Pass through policies (IE i can commit code by another), you may as well have no CLA. It's just overhead with no legal benefit. The benefit of CLA's is to have legal assertions about ownership and patents, from the people who wrote the code.

So without having the people who actually wrote the code make those assertions, you get nothing legally.

In those cases, or if it isn't your goal (like the DCO folks), you might as well move to the developers certificate of origin model, and get the same benefits, without any of the overhead.

The process is as follows:

1. Any Github user submits a PR. This user is not required to have a name or a valid email address.

2. Anyone with review access to the Rust repository (disclaimer: myself included) reviews the PR and leaves a comment on the commit. A bot sees the comment and queues the PR for integration.

I can't comment on the legal implications, but the effect of this process is that there is a very low barrier to entry to contributing and likely explains why the total number of contributors (as measured by Github) is so high.

As to the issue of potential relicensing, the Rust repo is already about as permissively licensed as it gets (a dual license of MIT/Apache 2.0). As far as I understand, this already means that anyone can take the code and relicense it at will (I believe this is exactly what LibreOffice did to OpenOffice). At that point you'd probably still need to distribute the MIT license with each of the original files, but new contributions (and the project as a whole) would be covered by GPL or what have you.

The Mozilla committer agreement is not a CLA as I understand the term - it does not assign copyright to Mozilla, copyright is retained by the original author. The purpose of the document is to assert that those contributing code have the legal authority to do so. In Rust's case, those with review power are the gatekeepers responsible for ensuring the provenance of the code.

it does not assign copyright to Mozilla

This is common to many CLAs (sane ones, at least). The Go CLA (really the Google CLA[1]) also does not assign copyright to the Go project, it gives them a license to "reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works"

[1] https://cla.developers.google.com/about/google-individual

Also contributors are not the same as committers in Github. And I've found that Github doesn't display Authors but only Committers. Example: https://github.com/golang/tools/commits/master/cmd/cover/fun...

One thing I love in Rust is that it purely makes use of the existing infrastructure that everybody knows - GitHub.

Every Google project uses its own repository, issue tracker, and mailing list. Even many Mozilla projects such as SpiderMonkey require some knowledge to access their infrastructure. However, almost all development in Rust are done only using GitHub. No external dependencies. One exception that is not part of GitHub would be the build bot, though it doesn't matter much.

I know that GitHub centralization is not a good sign, but Rust's all-in-one approach really lowers the barrier to entry significantly.

I've made several CLs like this commit [1], yet I am not seeing myself listed under contributors.

[1] https://github.com/golang/go/commit/912ec1990bd09f8fc128c3fa...

I believe the .../graphs/contributors page only shows the top 100 contributors (for Go it looks like the threshold for commits is approximately 6).

I'd like to mention that for me personally the biggest issues with the language so far is its unappealing name.

'Go' sounds like a bad sports drink.

Does anyone think the same?

Is it for the greater good to be inviting for more pragmatic thinkers (instead of people who care about aesthetics)?

Hmm - how did they manage to backdate the issue/issue comment creation? I don't see it in the GitHub API documentation.

Special process, working with support@github.com. They have an internal tool that will migrate a special format (which we had to prepare). After 14 tries, we got it right. Mostly. We still couldn't do lots of things we wanted, but it was way better than our first version where we did it all via API calls.