This post was originally posted on maurobringolf.ch
- Understand what the project does and explain how it works in a few sentences.
- Learn the APIs of the project and preferably use them in your own work.
- Read all documentation available.
- Look at the different modules and get a sense of how they interact.
- Follow current issues and pull requests on GitHub.
- Decide on one area to go deeper and start looking at test cases of these modules.
- Contribute documentation and tests. Fix typos and increase test coverage by 0.0x%.
- Focus on beginner issues and see how they are solved.
- Fix issues yourself.
And this is pretty much how I did it. Yesterday night my first feature contribution was merged into Babel 7.0, so it seems like a good point to evaluate the steps listed above. Have a look at the pull request and issue on GitHub if you are interested in the feature itself. It is a loose option for transforming ES2015 default parameters in a way that is technically not spec compliant but produces more optimized code.
Writing code of your first contributions is not going to be the hard part, but understanding the code around it is. I think my development time spent on Babel so far is roughly 60% reading code, 35% reading documentation and 5% writing code. I guess this will change over time, but I still expect to spend more time reading code than writing it.
At first it might seem like the project's documentation is extensive and awesome. And I guess from a high level view it very often is. You will see mistakes and gaps only after you dived deep into one aspect of a module. Then you might realize that documentation for that specific part is neither complete nor correct. I think improving documentation is one of the easiest, yet most valuable contributions we can make.
This is the biggest take away for me. I have been working with Git in a team for a year now. But open source has different latencies, people are not necessarily working on projects daily or weekly. My first version of the pull request below was approved but not merged for a month or so. And with over 300 contributors on the project my branch obviously got way behind its target. I tried to update it myself and messed up. It was the kind of Git chaos where you just want to delete everything and create a new branch or even repository. But I got help on the Babel Slack team and within a few commands I had a clean new branch that was merged a few minutes after. Git is really at the heart of open source and being fluent and confident with it will help you a lot. I have already collected some readings on Git and will probably write about it as well. Let's get better at Git!