A step-by-step guide to contributing to open source for the first time

or, The Sharks Are Photoshopped

I’m a front-end engineering student at Turing School. This week, I had to contribute to open source for a project.

Although I’m only two weeks and change away from graduation (!!!!!!!!) and being an official junior dev, it still felt daunting — I wasn’t ready! I was being rushed! I was being pushed into a situation I wasn’t ready for!

It felt like this:

(no children or sharks were harmed in the making of this gif. afaik.)

However. Let me assure anyone who wants to contribute to open source projects but is scared to begin, it actually turned out to be more like this:

aka, Not A Big Deal™

So worry not, friends. If I can do it, so can you.

Disclaimer time:Open source can sometimes be a minefield, it’s true.This article doesn’t pretend to furnish you with jerk-proof armor, but it will give you a few tips to help you find supportive, junior-dev-friendly projects.

Okay, enough chatter; let’s do this thing!

Finding open source projects

GitHub user MunGell has put together a totally excellent list of open source projects (and the list itself is open source — whoa) which are specifically “awesome for beginners”. It’s a great place to start.

Leverage GitHub’s search tools — specifically, look for repo issue labels.

Look at all these doable issues!

Just typing label:beginner into the search bar will bring up issues that the project’s devs consider appropriate for beginner programmers.
There’s no standardization of the issues labels — get creative when you’re searching.
Generally, a team that adds any type ofbeginner tags to their issues is going to be a supportive bunch.

Calling dibs on an open issue

When you’ve found an issue you want to try out, take a beat to be respectful:

Introduce yourself as a first-time contributor.
Find out if it’s already being worked on.
Be honest to yourself and the projects’ team about your abilities.

Brittany Storoz has written a succinct script to use:

Hi there! I’m a first-time contributor and was hoping to help out with this issue. I noticed nobody was assigned to it, but if there’s already a solution in progress I’m happy to try helping out elsewhere. Thanks!

Keep in mind that — sometimes — an issue earmarked for beginners might still be urgent. Be timely; if you can’t complete an issue in an appropriate timeframe, add a comment letting the team know.

It’s no good sitting on an issue (that someone else could be working on) if you’ve given up on it.

Getting started on the issue

In addition to a README.md that tells you how to install a local version of the app on your machine, many open source repos will include a CONTRIBUTING.md file that breaks down the steps of how to contribute to the project.

Take a beat to read over it — a lot of projects tell you exactly how to give yourself the best shot of having your PR merged into the codebase.

Read the CONTRIBUTING.md file if there is one.
Install the repo according to the README.md file.
Read the code! Look for stylistic choices, code sanitation practices, etc.
When you change something, be a good human and run the project test suite.

Submitting your PR (and screaming internally)

Double check your code: syntax error free, good commit message, etc.
When submitting a PR, make sure you follow the conventions set down in the CONTRIBUTING.md file.
If the team doesn’t already include a template for the PR, include: what change you made and why; what tests need to be written; what tests are failing and why; what still needs to be done; any other information that seems relevant.

Waiting for feedback (internal screaming intensifies)

The number one thing about waiting for feedback is:

Don’t expect feedback.

Feedback isn’t uncommon. What I’m saying here is: don’t build up an idea of what kind of feedback you’ll get. That way lies madness, or at least a bummer of a time.

And another important thing about feedback is:

Be gracious about feedback.

You might never get a response, you might get a response in the negative (they silently close your PR), or you might get a response that is negative (aka curt/mean/dismissive/derisive/generally jerkish).

Hopefully feedback will be kind and helpful. Some projects have active and passionate open source contributors that create discussion boards and leave verbose, constructive comments on PRs.

If you run into that, embrace the experience! Build out your network, and find mentors who will help you learn the open source ropes!

If you don’t … try another issue, another project, another repo.

Why contribute to open source at all?

It’s a nice thing to do.
It looks good on a resume/GitHub profile.
It grows your skills.
It helps you learn to be a good communicator.
It helps you become better at interpreting unfamiliar codebases.
It strengthens your “soft” skills (aka being patient, being thoughtful, being empathetic).
You get warm fuzzy feelings because you just participated in the idealistic concept that open source improves tech because a rising tide (aka shared knowledge) lifts all boats.
It can grow your network and broaden your professional horizons.
It’s a great way to start learning a new language/library/framework.
That’s enough reasons already!

Go for it!

Remember: the sharks are imaginary (or photoshopped), and even though scary deep water is a real thing, there are people out there who will cheerfully help you stand up in the shallow end (even if you flail a bit at first).

So get out there and flail ❤️