I would add "Make sure the maintainer of the repo will merge (or even look at) your PRs". I more than once had very reasonable PRs (bugfixes) waiting to be merged forever.
How to contribute to an open source project on GitHub
41–50 of 98 posts
Re: How to contribute to an open source project on GitHub
#42Wow! When you want to fix a typo, it can be as little as two hours!
Re: How to contribute to an open source project on GitHub
#43But what about designers?
Projects need design as well. Websites, logos, manuals/documentation: there are plenty of opportunities for designers as well.
https://news.ycombinator.com/item?id=12881822
If you could elaborate a bit on how to get involved in the non-programming piece for us non-programmers, like designers and copywriters, the world will be a slightly better place.
Thanks.
Re: How to contribute to an open source project on GitHub
#44For many projects, Github is just a place to publish yet another public repo. Using github issues and pull requests is a sure fire way to feel ignored. If you want to contribute, e-mail the lead maintainer. Do not submit patches to the ether. Do not think anyone will look at your patches. Having started several large open source projects, and started / worked for a number of open source companies, I can tell you the…
That doesn't sound like a sound advice.
If the author of the repo can't be bothered to look at the issue or a PR then I don't see how they'll be receptive to emails.
Most projects don't have other ways of contacting the people involved (very few list their e-mail addresses and even less have dedicated irc or slack channels).
Yes, it happens way too often that issues and PRs are ignored but realistically it's a strong signal to stop investing more time into such projects because it's unlikely things will improve.
Re: How to contribute to an open source project on GitHub
#45There is one very important tip that's missing: Follow the original coding style exactly . Not just spaces vs tabs or block styles, but idioms and other idiosyncrasies, too. Why? Imagine reading a source repo where every second block uses different bracket styles, mixing spaces with tabs and so on. It's going to look like a kludgy mess, and will be distracting to read. There is no correct style for most languages (pe…
> 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.
Re: How to contribute to an open source project on GitHub
#46There is one very important tip that's missing: Follow the original coding style exactly . Not just spaces vs tabs or block styles, but idioms and other idiosyncrasies, too. Why? Imagine reading a source repo where every second block uses different bracket styles, mixing spaces with tabs and so on. It's going to look like a kludgy mess, and will be distracting to read. There is no correct style for most languages (pe…
> 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.
It's more than that.
I've had a patch rejected because my unit tests used the wrong verification manner (java assertTrue() instead of assertThat() in cases where the latter would report better error messages were the test to fail, as I recall). Automatic blah will never catch this kind of thing.
Ditto for human-readable messages that have/lack full stops at the end.
Ditto for if() foo vs if() { foo } and the ever-lovely style question, are abbreviations such as TCP to be called TCP or Tcp in camelcased identifiers?
Style is largely a human matter.
Re: How to contribute to an open source project on GitHub
#47Earlier 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.
It's more than that. I've had a patch rejected because my unit tests used the wrong verification manner (java assertTrue() instead of assertThat() in cases where the latter would report better error messages were the test to fail, as I recall). Automatic blah will never catch this kind of thing. Ditto for human-readable messages that have/lack full stops at the end. Ditto for if() foo vs if() { foo } and the ever-lov…
> 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.
Re: How to contribute to an open source project on GitHub
#48There is a lot of overlap with Github's own guide to Contributing to Open Source [1] and Forking Projects [2]:
[1] https://guides.github.com/activities/contributing-to-open-so... [2] https://guides.github.com/activities/forking/
Re: How to contribute to an open source project on GitHub
#49This 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. Instead engage and discuss the Issue first and make sure it's actually something the project wants.
Don't just start writing code. Familiarize yourself with the codebase. This comes naturally if you are a user of the project, as you will naturally run into bugs or learn the software's behaviors and as you discuss the Issue or features with maintainers. There are far fewer right ways to build a feature than possible ways.
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.
Re: How to contribute to an open source project on GitHub
#50Is there a breakdown of top projects by language? I'm a C# developer and would love to put my skills to work on an open source project, but how do I find one?
Up-for-grabs lets you filter by language: