I also am scared off by the public aspect, and find it a very awkward requirement. If there was an option to create a private branch on Github, I'd probably use it often. I'd love if there was an easy way to submit a quick patch using only the Github interface. As it is, I've clicked once in my life on the fork button, realized that it created something visible to the outside world, and have never used it again. Instead, I make a local checkout, and generate patch files.

It's difficult for me to explain why I feel this way. The original stigma of 'fork' is definitely part of it, but most of it is just my distaste for visibility: it feels horribly immodest to associate myself with a project with which I probably have only a passing association. I can't defend my attitude, but it's probably worth noting that people like me (and apparently the author of the Go article) will be dissuaded if public affiliation is a requirement.

Now this is an interesting answer and i thank you for it. You don't have a problem that is in search of a solution. You have a real reason why github's publicity can actually be a bit hindering.

And i am even more grateful because it's truly a way i have not yet considered. See, for me github is a tool that i approach as dispassionately as my garage door opener. It is a thing with which i personally solve problems. Those problems are broken software or broken documentation. I use github to fix things. And i'm almost always doing so with a sense of nearly full confidence in that my issues or PRs will either fix a problem, or allow me to gain information so i can fix it. The only doubt i have is when i recognize the maintainer is not very skilled or otherwise mentally a little of the beaten path and might need some convincing.

The least concern i ever have is "someone might see what i'm doing", which is why i've ended up with 210 forks in my account. I didn't think that concern could ever be a thing since i started using Github long after the time when i last had reason to feel truly self-conscious about the code or documentation i'm creating, and you did remind me of the time before that point, so i can understand you now.

Maybe with time it will get better for you, maybe not. Please keep sending emails with patch files if that's what you feel most comfortable with.

And thank you. :)

I think that it's a little bit of a problem with a lot of the modern "social web" mindset; it all implies that you should feel comfortable doing everything in public, with the whole world watching you.

The problem is, there are people for whom this really doesn't work well. Some might just personally feel uncomfortable about it. Some might be concerned about future career prospects. Some might be women, who are worried about online harassment. Some might be people with stalkers, who are trying to avoid any kind of traceable online public trail.

This whole "share all the things" mentality leads to somewhat creepy exposure of everyone's private lives to governments, corporations, the general public (which can act as a mob on occasion), and also specific private individuals who you might be trying to avoid exposing things to.

So, if I understand correctly, it's the user oriented approach of Github that put you off ? Gitorious is project oriented, does that suits you more ?

The simplest reason is if what I was contributing was done on my employers time and they have strict IP restrictions. It is much, much easier to vet a single changeset than it is to a) verify a whole repo history and b) coordinate around my public/private github identities.

I'm not sure I understand. Vetting a changeset is basically the same thing as verifying the repo. Just look at the hash of repo A (your clone), check that it matches B (upstream), check that your repo A + "patch" matches pull request.

What am I missing?

Branches and the ref log.

And then I have to follow a completely different work flow and inconvenience the maintainers.

If PRs were a instantaneous thing, I don't think it would be a problem. However, if you've ever looked at a network graph of a repo that requires rigorous code review or doesn't have a diligent maintainer, some of those forks can sit in limbo for a really long time. And, as more pull requests pile up, it's very difficult as a user to figure out which version I should be using for my code to run correctly.

I just ran into this issue the other day when I was using Node with a lot of dependencies that still haven't been patched for issues that cropped up in OSX Yosemite.

> it's very difficult as a user to figure out which version I should be using for my code to run correctly.

I've rarely had trouble with assuming master (or ideally a tagged release) on the original repo (not a fork) is the one I should be using. Assume all forks are forks.

In any cases where this hasn't been true, it's been clear to me the blame is due to poor release management (or poor communication of release management, which is the same thing), rather than somehow the fault of github's PR or forking system. Although you can hypothetically argue that certain UI's encourage poor release management and others support it, I personally have not seen this to be an issue in github's UI.

    There are lots of reasons why I may not want my github
    fork to be public or I don't want to have a github fork
    at all

The authors of the Lua language develop in private. They like to experiment freely with ideas, many of which never see the light of day.

They said if people saw what they were doing in real time, it would probably cause mass panic among the community. (Oh no! You're removing feature X?)

Github didn't always distinguish well between repos you'd substantially authored and long-lived off-hand pull request forks. This made it annoying as a showcase of your work. Fortunately, they've made things much better now.