by Alaina Kafkes

How to Find Your Open Source Goldilocks Zone

Not too easy. Not too hard. Just right.


A few Fridays ago, I decided to participate in an amazing initiative that my friend Maxcell Wilson helped bring to life called Open Source Friday. The premise is simple: contribute to open source, because it’s Friday and why not? But for me, finding a suitable issue was anything but simple.

Frustrated by hours of scrolling through issues, I ended up making a pull request that was valued by the maintainers, yes. But that didn’t challenge me like I had hoped.

Contributing to open source is as much an opportunity to give back as it is to learn. I fulfilled only the former that Friday.

What made the search for a suitable issue so difficult?

As someone who has already had a few pull requests merged, I found that issues labeled “beginner” didn’t seem challenging enough. But as soon as I took “beginner” out of my search criteria, it felt hard to gauge the difficulty of issues with other labels or no labels at all.

Even worse, some of these more advanced issues had jargon-filled descriptions that turned me off from contributing.

How could I find my Goldilocks issue — one that stretched my skillset just right — in the chasm between beginner and advanced?

I gave up on my search for my Goldilocks issue on that fateful Open Source Friday. But ever since then, I’ve been brainstorming strategies to help myself and others find our Goldilocks issues.

Here’s my four-pronged approach:

Strategy #1: Start with your starred repositories.

If you starred a repository, you probably care about it. Perhaps you’ve used it before in a personal project. Perhaps it just seemed cool at the time. Whatever it is, the thing that caused you to star a repository may in turn motivate you to contribute to it.

Plus, browsing your starred repositories for open issues feels less overwhelming and impersonal than turning to the gamble that is GitHub’s search bar.

Strategy #2: Leverage your personal network to find trustworthy open source communities.

Do you follow someone on Twitter who maintains an open source project? Do you have a friend who recently tackled an issue? Ask them about their experiences in open source! Use their guidance in order to find warm, accepting open source communities that are willing to answer your questions and review your code when you work on one of their project’s issues.

If you don’t have any connections in open source, at the very least you can look for projects with a code of conduct. Because the community vibe can make or break your open source experience, finding a supportive environment matters.

Strategy #3: If you don’t want to work on documentation again, move on to tests.

Writing documentation is a common rite of passage for beginners in open source.

I don’t wish to downplay the importance of good documentation — after all, a well-documented repository is the hallmark of a project worth contributing to — but in order to push yourself as a programmer, it is crucial to code.

Writing tests gives you the chance familiarize yourself with the project’s codebase and demonstrate your understanding of it by addressing testing for all possible cases. Getting more comfortable with a large codebase can even ease you into future open source contributions.

Strategy #4: Check how responsive maintainers are.

Do maintainers acknowledge new issues in a reasonable amount of time? Do maintainers frequently discuss the project with contributors via GitHub, Slack, or Gitter?

Communication is key in maintainer-contributor relations. The nature and number of exchanges you have with a maintainer — or, at least, with a frequent contributor — will have a huge impact on your open source experience.

Choose to contribute to projects that have maintainers and frequent contributors who are willing to collaborate with you especially if you start to struggle to make your contribution. Set yourself up in an environment where you don’t have to be afraid to ask questions!

How I applied these tips to find my Goldilocks issue

I decided to put my own advice to the test and find my Goldilocks issue.

The first strategy suited me perfectly: upon scanning through my starred repositories, I found an issue within Socratic’s mathsteps that has pushed me to get comfortable diving into large JavaScript codebases. What’s more, I’ve been lucky to work with maintainer Evy Kassirer who is wonderful at handling the barrage of questions I ask.

Lucky you: it looks like Friday is another Open Source Friday (every Friday is Open Source Friday). With these four strategies in mind, go seek out your Goldilocks issue and contribute to open source!

Enjoy what you read? Spread the love by liking and sharing this piece. Have thoughts or questions? Reach out to me on Twitter or in the comments below. Thanks for reading!