Live data from Hacker News

How to contribute to an open source project on GitHub

blog.davidecoppola.com

91–98 of 98 posts

Re: How to contribute to an open source project on GitHub

#91
post #49

This guide is heavy on the mechanical side and misses a lot of important substantive parts, if your goal is to add value to an open source project. Don't just create a fork, branch, and submit a PR without context. First, make sure the intent of your change is actually desired. Just because someone opened an Issue does not mean that it belongs in the project. Anyone in the world can open a Github Issue for any reason…

| Finally, understand that your contribution is not "free" for the project. It takes time and consideration to even look at your PR and even more to code review it. The more popular the project, the more true this is.

Understand code interactions: they scale N^2 with each new feature added. Specifically, each interaction your feature has with all the other features has to be coded, and then each new feature might interact with yours. This is the curse of scope freak.

It is the sole responsibility of the PM/owner of the project to select which features worth this.

Re: How to contribute to an open source project on GitHub

#93
post #45

Earlier quoted context omitted.

> Follow the original coding style exactly. Personally I would take any formatting and just run an auto-formatter over the code section when I work on it the next time in case it bothers me. Correct and sane code are far more important than hassling someone else to conform to a particular style. In my opinion applying styles is a task for machines, not humans.

Well, you can't do that when reading code on github.com, for example. Even if I have the code checked out, I don't want to clutter my diff with hundreds of reformatted lines just to read it. It sounds like formatting isn't important for your code comprehension. That's nice for you, but for many of us, that's just not how our brains work.

But if you just shift the burden from yourself to someone else that's a zero-sum game, not an improvement.

Instead a formatter should be applied via a commit hook and github should provide a what-if version of the pull request with the hooks applied.

Re: How to contribute to an open source project on GitHub

#95
post #89
post #47

Earlier quoted context omitted.

> Ditto for if() foo vs if() { foo } At least that one can be fixed automatically by eclipse. But sure, there are some things that are difficult to automate. What I'm saying that one should not hassle a contributor over all those things that that can be done by machines.

How is that "hassle"? Somebody needs to fix it, why should it be the maintainer? In my experience, not even bothering with style is a good indicator of careless "shotgun coding" and such PRs typically have far worse issues. It's also typical that such PRs won't have real issues fixed either.

> why should it be the maintainer?

I'm saying: Why should it be either human?

> In my experience, [...]

That seems fairly dismissive to me. An expert in a certain area can certainly fix smaller issues with a few lines of code but only have a limited amount of time on their hands. Having to read a lengthy style guide and making sure they adhere to every single rule, especially when those rules are the opposite of their regular habits, is a non-zero hurdle to contributing.

Offloading that work to a machine as far as possible lowers the burden to only those rules that cannot be applied automatically.

Re: How to contribute to an open source project on GitHub

#96

I dislike the idea of using 'origin' for my own remote name. I keep 'origin' as the canonical remote and my local master branch tracks origin/master. I use people's usernames for their remotes (including for my own). If I'm pushing a feature branch to my own remote: git push -u myusername mybranchname If I need to checkout someone's PR, it's: git remote add theirusername git@github.com:theirusername/repo.git git fetc…

FYI: GitHub will create a branch in your repo for pull requests. You shouldn't need to pull directly from someone else's repo just to look at their pull request.

http://stackoverflow.com/a/30584951

Re: How to contribute to an open source project on GitHub

#97
post #83

Earlier quoted context omitted.

Complaining about freely volunteered advice people give you in a friendly and helpful spirit is a good way to avoid getting it.

Well, that isn't what I was doing. Since you are not among those being actually helpful to me in this discussion, you are more than welcome to stay out of it if you feel that some remark of mine somehow constitutes bad behavior. I have upvoted every single reply that was useful to me and said thanks twice.

What were you doing? If someone volunteers advice, just be appreciative and try it if you want. Don't slag them off if it doesn't work out for you. It's not their fault they don't understand everything about what you need to do to implement their advice.

Re: How to contribute to an open source project on GitHub

#98
post #96

I dislike the idea of using 'origin' for my own remote name. I keep 'origin' as the canonical remote and my local master branch tracks origin/master. I use people's usernames for their remotes (including for my own). If I'm pushing a feature branch to my own remote: git push -u myusername mybranchname If I need to checkout someone's PR, it's: git remote add theirusername git@github.com:theirusername/repo.git git fetc…

FYI: GitHub will create a branch in your repo for pull requests. You shouldn't need to pull directly from someone else's repo just to look at their pull request. http://stackoverflow.com/a/30584951

Didn't know you could pull by ID! Thanks!
Post reply on HN