About two months ago I realized that contributing to open source is a massive opportunity where I could gain experience in large production code bases while ideally helping someone on the way. In JavaScript land there are a lot of projects that actively help new contributors getting started. The one that fascinates me the most is Babel. Babel is a JavaScript source to source compiler and has been a topic on this blog before as well. I like making plans, so I came up with one on how I was going to land my first contribution in Babel. These are the steps I wrote down for myself:

  1. Understand what the project does and explain how it works in a few sentences.
  2. Learn the APIs of the project and preferably use them in your own work.
  3. Read all documentation available.
  4. Look at the different modules and get a sense of how they interact.
  5. Follow current issues and pull requests on GitHub.
  6. Decide on one area to go deeper and start looking at test cases of these module.
  7. Contribute documentation and tests. Fix typos and increase test coverage by 0.0x%.
  8. Focus on beginner issues and see how they are solved.
  9. Fix issues yourself.

And this is pretty much how I did it. Yesterday night my first feature contribution was merged into Babel 7.01, 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 is not the hard part

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.

Documentation is not necessarily complete or even correct

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.

Get better at Git

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!

Directed acyclic graph