Contributing to Open Source
This article is for beginners to open source contribution.
Contributing to open source software is in many ways a right of passage to the developer community. Like your first romantic kiss, except important. How important? Important enough to show up in interviews(open source, not kisses), enough to power tensorflow(machine learning, the future), enough that Microsoft’s vscode is open source.
But if you’re here then you probably don’t need convincing. You’re here because you want a step by step guide on the how of contributing to open source.
Although not necessary, a firm understanding of github basics will help with making your first contribution. Here is a good article if you feel you might need a refresher on the Gitflow.
Let’s break this down into steps and then go through those steps on by one.
- Find a repo.
- Fork that repo.
- Clone that repo.
- Make your changes.
- Push your changes(to your fork).
- Create a pull request.
1. Find a repo.
This might sound simple, but it’s not, and so allow yourself extra time to search for the right one for you. Otherwise you might get burnt out before you finish your idea. Take the extra time to learn as much as you can about the cause the repo is supporting even if it’s just a video game.
You’ll want to sort the repos by their tags. You can use the search bar at the top of the github website to look for specific repos that would best suit your skills.
Read the README.md file. I won’t say never, but hardly ever will you spend too much time reading the existing code and getting a feel for the coding style. Notice the style of the repo to which you are contributing. If applicable; use double quotes if that’s the convention of that repo, notice the tab size. These conventions will most likely be spelled out in a CONTRIBUTING.md file, or some other aptly named file. Read through those guidelines carefully.
Check the issues ta for problems that the maintainer(s) specifically want help solving. Using the “beginner-friendly” as a search query will turn up repos that will sometimes walk beginners through their first contribution.
2. Fork That Repo
The next three steps are/should be self explanatory but they are worth taking a few lines to remind ourselves because we’ve all felt or will feel the annoyance of accidentally working on a clone of the maintainers repo instead of a clone of our own fork.
3. Clone That Repo
Again, be sure you are cloning your fork and not the repo that you will be making a pull request against.
4. Make Your Changes
If you’re a beginner this might be as simple as copying code from the posted issue on github and pasting it where instructed. Other developers want to involve the community. They know that new developers represent a future of new ideas and different approaches to solving problems.
For your first few commits I would encourage looking for repos that have issue you can immediately solve. I think the goal for these first few contributions should be to familiarize yourself with the process and allay some of the imposter syndrome that may be holding you back.
5. Push Your changes(to Your Fork)
Include a descriptive commit message telling what and not how, maintainers can see the how for themselves in your code. It is nice to keep this commit message brief, think 180 characters or less, but more importantly make it understandable to someone with your context.
A message such as, “code working”, is not a good message; try instead, “Added *functionName* function to do *x*”.
And push your code up to your remote repository.
6. Create a Pull Request
Once your changes exist on your fork you will got to the ‘Pull Requests’ tab and click on the green ‘New Pull Requests’ button.
Now check to make sure that you are specifying the correct branches of each repo and that the arrow is pointing towards the repo that that pull request will be made against.
In your pull request you will see another text box for adding notes. This is a good place to communicate with the maintainer that will be reviewing your pull request. This can help you send along any comments that you might not think appropriate for the commit message but that you still want to convey to the maintainer.
Last but not least, remember that maintainers are often not paid to maintain the project you are making the request against. They also may be dealing with many requests. Be patient, move this project to the back burner.
If you have any additional questions or comments feel free to leave them in the comments below or reach out to me on github or to email me: hyrum.butler3@gmail.com
