Live data from Hacker News

How to contribute to an open source project on GitHub

blog.davidecoppola.com

21–30 of 98 posts

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

#22
post #14

There 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…

Right! And a lot of projects have a linter in place that runs in continuous integration (travis, etc) that you can see in the PR or just locally.

In Babel we use ESLint for this https://github.com/babel/babel/blob/master/Makefile#L20-L27

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

#23

Is 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?

Not the best way to find an open source project to contribute to but you can check trending per language https://github.com/trending/csharp or the top starred repos that are C# https://github.com/search?l=C%23&q=language%3AC%23&ref=advse....

I'd be much easier to find a project you use or know about so you have a lot more context into the project, it's usage, documentation, etc.

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

#24
post #5

Step 1: stumble upon a terrible bug (or that really obvious missing feature that _should_ be there) in your favorite library / framework / app. Step 2: rant about it on HN / Github issues / whatever. Step 3 (optional): try to reach developers on GitHub and get the obligatory "pull requests are welcome" response. Step 4: In frustration, clone the repository, fix the damn bug and submit your pull request. Steps 5..41:…

> Step 4: In frustration...

Step 4 requires no frustration. It should be a relief you can fix it yourself rather than hope for some opaque engineering team to maybe fix it at some future date since your company doesn't have the Platinum Support package.

> Steps 5..41: ...

I think maintainers of small projects should do their best to merge whatever is given to them without back and forth or delay--just a prompt and sincere thanks. There's no reason to treat contributors like junior devs you're trying to teach and guide. Sometimes that requires swallowing some pride in having the code be just right or means you may want to fix up a few things after the merge.

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

#25
post #24
post #5

Step 1: stumble upon a terrible bug (or that really obvious missing feature that _should_ be there) in your favorite library / framework / app. Step 2: rant about it on HN / Github issues / whatever. Step 3 (optional): try to reach developers on GitHub and get the obligatory "pull requests are welcome" response. Step 4: In frustration, clone the repository, fix the damn bug and submit your pull request. Steps 5..41:…

> Step 4: In frustration... Step 4 requires no frustration. It should be a relief you can fix it yourself rather than hope for some opaque engineering team to maybe fix it at some future date since your company doesn't have the Platinum Support package. > Steps 5..41: ... I think maintainers of small projects should do their best to merge whatever is given to them without back and forth or delay--just a prompt and si…

As a maintainer of small project I would say that it depends. If the code is really useful and contributor is not willing to fix any of my comments, I would merge it anyway and fix it myself. If the code is so bad that it would be easier for me to completely re-write it myself, I would reject it.

I'd like to think that my code review comments are reasonable most of the time, so it doesn't usually take more than 2 or 3 iterations to complete a pull request.

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

#26

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…

Same here. Except I use 'myfork' as the name for my remote repo. Origin/upstream always got me confused when I first started learning Git, so I created my own naming conventions.

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

#30

what if I want to start my contribution I just don't know which project to choose ? this assumes that I already know the project I want to contribute to.

Usually people begin by contributing to projects which they already use. For a beginner, it might be better to start contributing to a project which is mainly written in the language which they're familiar with. Also, try to find a project which is beginner friendly; they usually have some issues marked as 'beginner' or 'good first bug', and also have a CONTRIBUTING.md page.

Bonus: A good idea is to start contributing to a project which contain problems sets to be solved by coding the solutions in a particular language. You could send PRs for creating/implementing some problems. http://exercism.io/ is a good example.

Post reply on HN