The repo that became its own good-first-issue

Source: Dev.to

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!