The repo that became its own good-first-issue

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 di