I had my first pull request merged recently! 🎉

It was exciting, and I learned a lot along the way. For those of you looking to get involved in open source, this post is my attempt at helping you take that first step by retracing my journey.

Baby Steps

Before you even begin thinking about contributing, I actually suggest to take a step back and do the following:

1. Use lots of different open source libraries.
   • Finding a project you are excited about contributing to is understated in my opinion. One off contributions are great, but continual contributions are even better.
2. Answer questions for those libraries on StackOverflow or in chat channels.
   • This will help familiarize yourself with every corner of the documentation and may even force you into diving into the code base. You’ll learn how people are using a library and you may even learn a new trick or two.

If you spend time doing this, you’ll already be contributing to open source in a roundabout way - you’re helping keep questions off the issue tracker.

First Words

As you build your expertise helping people, you will inevitably find issues with documentation. Maybe there’s a misspelling, a grammatical mistake, or a part of the API that is completely undocumented. This is inevitable as open source projects are built on the contributions of people from around the world. There is rarely time or money spent having technical writers make professional documentation. This is where you’re going to cut your teeth on open source.

So I flubbed a bit when I said it was my first merged pull request. It wasn’t. I’ve had documentation pull requests merged in the past, and that is how I got started. By doing this, I learned how to:

• Read the contributor guidelines.
• Converse with maintainers & the community.
• Create new issues if needed; maybe you found an actual bug.
• Submit a pull request on Github.
• Update a pull request with suggestions from the maintainers.

This taught me that getting involved in open source wasn’t as simple as diving in and fixing some bug. You’re participating in a community and there’s a learning curve to that; especially for us introverts. There’s a good reason why everyone suggests helping out with documentation as a good first step.

Exploration

Once you’re familiar with a project and feel confident in your ability to help out, it’s time to dive into the bug tracker. If you’re lucky, maybe there’s a bug you submitted or ran into that seems fixable. If not, checking out the labels and looking for something labeled Good First Issue or Good First PR is the perfect place to start.

Me? I got lucky and the first issue I tried to tackle was both a Good First Issue and a bug that I had run into multiple times in the past. It was time to fix it!

The Scientific Method

You’re going to notice that a lot of people ignore the issue template and rarely include anything more than a short description of the bug. So before you can even begin to try and fix a bug, my advice it to put on your QA hat and turn that ticket into something workable:

• Find reliable reproduction steps.
• Write a minimal code example that can reproduce the bug.
• Identify affected systems (OS, devices, library versions, etc.).
• Write a clear problem statement explaining the bug. Remember to KISS.
• State the correct expected behavior.
  • If you’re unsure what that is, then propose what you think the correct behavior should be and why.

Those are the minimum steps required of any QA Analyst (speaking from experience). If you can give that to a dev, it will make fixing the issue magnitudes easier.

Experimentation

With a fully fleshed out bug ticket in hand, you can now dive in and try to fix it yourself. Exploring any new code base is going to be a challenge, but hopefully your experience using the library and answering questions will give you a running start. Barring that, my best advice is to use copious amounts of print statements to first understand the flow of the code. On React Native, you’d use commands like this:

12

// JavaScript
console.log(message);

For native modules:

123456

//Android
import android.util.Log;

Log.d("ReactNative", message);
// This will then show up when you use this command in the terminal:
// adb logcat *:S ReactNative:V ReactNativeJS:V

123

// iOS
RCTLogInfo(@"your_message_here");
// This will show up in your debugger console along with your JavaScript logs.

You don’t have to go all the way of making a flowchart like back during your CS course or internship days, but you do need to understand the logical structure well enough to pinpoint the root cause of the error.

In the bug I fixed, I was able to trace the offending behavior back to a single line of code. From there, I was able to research and learn about how React Native bubbles up events on iOS and lo and behold, the root cause was found.

Sharing

At this point, fixing the bug is not that far out of reach. A bit of extra research or poking around in the code base might be required, but you’ll probably see a few different ways to fix the issue. So what’s the best approach?

This is where your prior experience conversing with the community kicks back in. You can:

• open a dialog using your findings,
• ping some maintainers with @,
• or just open a pull request with what you think is the best approach.

Suggestions and code will be reviewed, edits made, and eventually your pull request will be merged. Just don’t forget to update that documentation if needed!

Community

That’s it! The end to the wild ride of your first commit.

It’s up to you now to continue contributing to this same project or go out and look for others to help. No pressure on sticking around. If this wasn’t the right community for you, then start all over again. Only this time you’ll be a seasoned explorer! 🔍

Copyright © 2011-2020 Ho Yin Cheng