The following is a guest post by Nikhil Thomas and originally appeared on his blog. Nikhil is currently a student a The Flatiron School. You can learn more about him here, or follow him on twitter here.
One of the things we have to do at the Flatiron School is contribute to open source projects. As a beginner, it’s pretty scary to think about writing code that experts will review and countless people may use. Where do you even start?
I needed some inspiration and found a great resource on Speakerdeck. Michael Koziarski, a Rails core contributor gave a talk called Lessons from the Other Side: Effectively Contributing to Open Source. It’s essentially advice from a maintainer of a huge project on how any individual can contribute to open source code. I’ll summarize some of my takeaways from these slides.
Don’t go looking for problems to solve!
It almost seems counterintuitive, but you’re much better off not hunting down tiny issues. Michael suggests tackling issues as they come up in your every day work.
You don’t need to reinvent the wheel. The best way to start is simply to start taking notes on any issues that arise as you’re coding in your daily life. Let the problems come to you.
Submit your suggestions in small, digestible chunks
The smaller your individual contributions, the more specific the issue you’re solving. Think about it from the view of the project maintainer – chances are she has a day job. Nobody wants to spend precious free time reviewing a massive pull request! Make it small, make it clear.
Documentation needs love too
My friend Kevin Curtin started learning Ruby in a formal environment on October 2nd, 2012. Just after a week and a half, he was able to submit an open source contribution to the SQLite3 gem. It wasn’t magic, and he talks about it at his blog. Chances are that most coders want to solve the sexy problem – writing code that’ll connect all the world via a massive search engine that only accepts 140 characters. Or something.
However, when a newbie is trying to learn code, they need simple and descriptive documentation. If you had a problem with any documentation, submit an explanation and example! Don’t worry if you’re afraid it’s not glorious enough, there are plenty of good coders. Good coders who can teach are a rarity – learn how to explain concepts in documentation and you’ll both strengthen your learning as well as make a name for yourself.
Did I miss anything? I’d love to hear from any open source project maintainers who have more suggestions for people! In the mean time, follow me on Twitter at @nikhilthomas90 and let me know what else is on your mind!
Make yourself useful.