Contributing to an Open Source Project

Full disclaimer: I have submitted a whopping two pull requests that have yet to be approved/reviewed. With that being said, I am far from an expert but I think that's exactly what qualifies me to make this post. I still feel extremely intimidated to make changes to the code. I don't really know what I'm doing but I'm figuring it out and so can you. If you're reading this, I'm not far from where you are.

I have wanted to contribute to open source projects for a long time but never had the courage to take the leap. Everything about the process just seemed overwhelming. A lot of the advice on the internet made it seem so easy. Just pick a project you already use and and find a "good first issue" and make the pull request. Well... sure but when the code base is massive, what do you do? How do you even go about trying to tackle even the simplest of tasks. It feels like everyone else is a master programmer and you're just a scrub.

My first piece of advice is to find a good community to begin contributing to. This is easier said than done but a few tips that may help. Look to see if they have contributing guidelines and get a feel for whether they're okay with helping new contributors. See they have a discord server or IRC where you can go and see how the community interacts. At the end of the day, you're doing unpaid work so as long as you don't make yourself a nuisance, I'm sure most communities would welcome the support. On the flip side of that, having to hold somebody's hand is a lot of work and effort. It would me much faster and less headache for them to just do a task themselves.

This isn't really a technical how to as there a much better resources than I could ever make but I'll cover the basics quickly. The first thing you're going to want to do is fork the repo. Next, you'll download a copy of your forked repo to your machine. Make sure that you can get it compiled.

Okay, now that you have accomplished this, stop. Don't try to look through the code. Don't try to understand how it works. If this is a project that many people actually use, you're not going to be able to figure it out and that's okay. We're going to take a different approach and one that I would argue makes it seem less daunting. You're going to go through the issues tab and try to find something that doesn't seem that hard to do. There's a labels tab that you can use to filter. In my experience, the good first issues aren't always the most straight forward.

Now, a big caveat that I didn't realize at first was that the issues are community generated. Anybody can go in there and post an issue. I would make sure that the maintainers of the project actually want that feature implemented. Find an issue that you think you could solve and see if they've been reviewed by somebody on the maintainers list. See if they green lit the feature to be implemented. If not, post a comment and say, hey this is something that I would like to tackle. See what the maintainers say. Maybe they could give you an idea of where to start or maybe they will just say okay.

No matter what they say, I would say that you should try and implement the change regardless. Its good practice and it will help you begin to get familiar with the code base. Always create a separate branch for the feature of bug you're going to add/fix. So, this is where grep or similar tools come in handy. Use grep for keywords that you think might help you find the code that is responsible for what you're trying to work on. You may have to set a lot of breakpoints and trace the code but really really try to get to the code yourself. If you're really stuck, you can go back to the issue and post a comment that you're having a hard time finding the code responsible for whatever you're trying to work on and see if someone could give you a tip on where you could try looking. I would say this should be a last resort. If they have to find the code for you, at that point, they might as well just implement the feature themselves, you know? In my very limited experience, finding where something is implemented is the biggest battle.

Okay, now that you've found the code, try to understand how it works. Is your change going to have any unexpected consequences? Is anything else going to be impacted? Try to QA your changes. Keep any code that you write in the same style as the code around it. If they're using camel case, don't start adding snake case. Keep it consistent. You're a guest in someones house.

After your changes have been made, push your changes to your repo and make the pull request. Try to be as descriptive as possible. Link to the original issue. Include screenshots. Remember, maintainers are also usually working for free. They have a lot on their plates. The easier you make your changes to review, the smoother your experience will be. 

After you submit your pull request you're going to be filled with adrenaline... at least I was. Try to relax and give them sometime to look over your changes. It may take a few days. Just check in frequently to see if they propose any changes for you to make or any other feedback.

That's about all I have at this point. Enjoy the process. Remember that everyone is human with their own lives. Try to make things easier for them.