Getting Started
So you’ve tracked down your first Open Source Project and now it’s time to figure out how to contribute.
The best place for guidance is reading the README. Every Open Source Project should have a well made README that helps explain what the project is and how you can contribute.
Unity Station goes above and beyond and even has a quick start guide to their project found here. Don’t expect every project to have something like this, but if they do, you probably found yourself some open source gold.
Finding Your First Issue
The issues tab on a Github repo is where you’ll find all the bugs, features and possible future ideas that the team is working on. For example, you can find Unity Station’s issue page here.
When you’re searching the issues page, it helps to use labels to narrow down your search. Starting out I look for labels with something like “Good First Issue”. This signals that you shouldn’t have to know too much about the code base or the project in order to dive right in and contribute.
Other possible first issue tags may also be found using “Up For Grabs” or “Bug”. If you aren’t feeling confident to dive into code yet, some Open Source Projects will even have a “No Coding” label.
Setting Up Your Environment
Once you’ve tracked down an issue, it’s time to figure out how to configure your environment to work on the project. Some projects will have great READMEs explaining how to do this. As an example, Unity Station has an amazing guide to help newbies setting up their environment found here.
When working on Unity projects, it’s important to remember that you’re using the same version that the project requests. If you use a different one, it will try to make the project work on your local version and can really mess things up when you commit them. You can add different versions of Unity by using the UnityHub Installs page shown below.
Dive Deep and Hit The Issue
Whatever issue you have chosen to work on, dive in and understand exactly where the issue you picked fits into the project and begin to take the time to understand all the components/classes/objects around it.
It can be very intimidating at first when you’re bombarded with hundreds of different scripts, but push through it.
Stumbling into my first issue it took me a hours before I knew where to go with it. I was exposed to great implementations to problems and learned so much by reading other developers code. After gaining a firm understanding of the issue I was working on, it didn’t take long to fix the issue.
Making Your First Contribution
Before you submit, make sure to test your code and double check it for whatever guidelines are laid out in the README. I know I’ve linked Unity Station a bunch throughout this blog, but they do a great job with their guidelines so here is another link as an example.
If everything looks good to go, make a merge request and pray to the binary gods that your code will be deemed worthy by an administrators. The worse thing that happens here is they reject it or your code does not pass automated tests. If this happens, you fix whatever they said the problem was and you make another merge request.
Mission Accomplished
That’s it. That was my journey into finding an Open Source Project and contributing to it. As of today, my code is live and in production. It’s cool to see it out there in the world. I’ve done a thing. I made the world a little better for people who needed help. It’s made me a better programmer and I feel a solid amount of self accomplishment.
Hopefully this will help encourage someone get off their butt and help contribute to an Open Source Project. It will 100% be worth doing. Trust me. I’m a stranger on the internet.