The easy fixes probably aren’t in your code

Labeling issues as “easyfix” is a common suggestion for making your project welcoming to new contributors. It’s good advice, but it misses an important fact: for mature projects, the easy stuff worth doing has already been done. I had this realization when I read Robert Haas’s post “Hacking on PostgreSQL is really hard.” In particular, a comment from Greg Smith:

The thing I like to remind people is that this project has been around for decades, during which over a hundred people (or whatever COUNT(*) FROM contributors is) have picked through the code trying to find low hanging fruit to contribute. Everything left to do is astonishingly hard; if it weren’t it would have been done already.

Greg Smith

But the good news is that there are probably still easy fixes to be found; they’re just not in the code. Most projects are heavily weighted toward code contributions. This means you have plenty of opportunities to highlight easy contributions. Do you have gaps in the test coverage? Easyfix! Do your demos need wording improvements? Easyfix! Have you checked the website for broken links? Easyfix! Does the code need linting fixes? Easyfix! (See? You’re not entirely out of easy code fixes.)

“Easyfix” candidates are typically small and often low priority. That doesn’t make them unimportant. They improve your project, and — more critically — they give potential significant contributors a starting point. The areas where you lack skill or interest are a great place to grow a more diverse contributor base. So if you’re dismayed because you can’t find “easyfix” issues in your code, look elsewhere.

This post’s featured photo by Raimond Klavins on Unsplash.