The repo that became its own good-first-issue

drkrillo — Fri, 05 Jun 2026 15:36:56 +0000

I've always loved teaching and helping others achieve things. There is a huge sense of accomplishment leveraging someone else's abilities. Not only telling them "you can!", but rather help them feel "I can".

I was working as a developer for some time when I decided it was time to contribute to other projects. But, honestly, finding the right project, the right issue, and having the right timing was much harder than what I expected initially. I decided to create something that could help me out: scrape some orgs, find good-first-issue labels, and aggregate them together in a README file.

Contributing to Open Source isn't easy for many reasons:

The obvious, the technical: finding your first technically possible contribution is a combination of the right language, the right depth, and knowing which repo to search in.

good-first-issues tackled that by scraping the language and the issue title to somewhat give me a little of context to start with.

The not so obvious, the human side of it. My first contribution(s) were hard because I felt exposed, my weaknesses were in the wild for everyone to see and point them out to me. At least that was how I felt. And once I found the right issue, and I decided to give that step forward, many times I didn't get an answer back. That kills any motivation left. Probably PR ghosting is the biggest reason why someone quits their willingness to contribute to OSS.

At first, good-first-issues was just a place others could come to find issues. But I realised it could be that issue. There were functionalities I wanted to bring and either I didn't have the time, or didn't have on the top of my head how to do them. "I can kill two birds with one stone" I thought. I knew where I wanted the repo to go, and I wanted it to be community-driven.

Creating good self-contained, clear and approachable issues is an art in itself: I didn't want to create the obvious "Fix this typo" (which I did initially) or "Add your name as a contributor" issues. But I didn't want "Build X layer" either. I understood the power of a good labeling framework: help a contributor find their ideal issue easily.

If my repo is meant to help onboard people into Open Source, reviews need to be substantial too. The issues I am building are not for my personal sake of getting the features done, only. It has a mentoring side too. I try to give constructive feedback every time I can, point out a resource, highlight things nicely done, and others that can be improved. I try to be the maintainer I would like to come across when contributing myself.

There are of course many obstacles to sort:

it's really hard to make a contributor stay. We all have too many things in our head, and making this repo a recurring thing in yours is not an easy task.
contribution farming is a real pain in the ass, worth writing a full article on this.

During the last month or so, 13 people have contributed. I know that doesn't read as huge, but it is for me. Knowing I am building something with others is much more fulfilling than building something I am the only one that knows it exists.

If you are reading this, and would like to be part of it, feel free to reply here, open a discussion, comment or create an issue. If you would like to read more about one of the topics touched here, also let me know.

Thanks for your time! And happy contributing!

DEV Community: drkrillo

The repo that became its own good-first-issue