or how I learned to stop worrying and love the “good first issue”.
The common wisdom nowadays (note that it is currently September 19th, 2024) is that junior developers should curate a good GitHub profile that shows your technical mastery of a wide range of problems, technologies, and languages because “having an impressive GitHub profile can open doors to exciting opportunities” [1]. If you’re anything like me, sorry if you are, then the minute you got your first job you basically stopped trying to contribute to open source projects. I distinctly remember the first time I tried to contribute to open source, I got overwhelmed by forking the repository [2], actually getting testing and linting suites to pass in GitHub Actions, and overall not feeling discouraged whenever the maintainer might request lots of changes to your pull request [3].
Given that, I basically threw out the idea that contributing to open source was worthwhile and started searching out articles to match this prior [4] [5]. But, as with everything in life, after many years working in the industry and getting experience with different open source tools, languages, and technologies, I do believe that contributing to open source projects is not only useful but necessary [6].
Okay, now that all of our priors have been aligned, maybe we can figure out where to start for contributing to an open source project. A quick search online shows a myriad of articles on where to start:
That’s great and all, but a lot of this advice is dependent on being aware of the different open source libraries and knowing which ones you would want to contribute to. That’s not always the case for new (and even experienced) developers. When I first re-entered this landscape, I kind of just looked at various libraries I had used recently:
One thing you’ll notice about these repos is there are either not many issues, or the “good first issues” are very stale and have PRs already attached to them.
Well, what now.
For me, I just put away my laptop for a bit and decided, again, that open source contribution is not really useful. But, after a few days, I opened up these repos again and decided that, even if some of these issues are stale or already had PRs associated with them, I would give them a chance just to get a feel for the repo. I initially did this because I wanted to get a better feel for the repositories and, hopefully, be ready to respond to any new “good first issues” that might arise in the future. But, what I found is that a lot of these issues were still relevant or the PR that was opened didn’t actually fully address the problem. Luckily, addressing these issues ended up with my PRs getting merged into the libraries.
Some examples:
Yeah that might have been a bit self-aggrandizing, but, really, what I learned is that a lot of first issues actually are quite good for understanding the library, despite what many people might say. Obviously most advice taken from a blog must be taken with a massive pinch of salt, but if there’s one thing to take away from my ramblings, just code. Fork the repo, find an issue, and then just code. Break the tests. Make bad mistakes. But, ultimately, just code. Over time your code will get better and your contributions will improve to. Below are a few aggregators that I found that are useful.