HN Explorer

Ask HN: Why do maintainers spend time reviewing my code?

5 points by dils ↗ HN
Recently, I was working on various open source projects. Mostly I was working on issues labelled as "good first issues". Before I start working on a issue I usually take a look at the previous attempts made by other people. Usually I can find a couple of PRs or comments if the issue is older than one year. Looking at the work history sometimes it becomes obvious why previous attempts were not successful: someone completely misunderstood the task and went the wrong direction, someone can barely code, someone is just pinging the contributors instead of doing the actual work[1]. What was surprising to me was that the maintainers almost always found time to answer every question, review ridiculously bad and incorrect PRs and spend days communicating with the contributor (including me) to give feedback about the work, while they themselves could absolutely resolve the issue in less than an hour. To be honest I don't understand why someone with 10+ years of experience would spend time reviewing my "good first issue" PRs like they don't have anything else to do. I am trying to be useful and to learn but I don’t want to bother anyone or waste anyone’s time and that's why I am wondering why would maintainers spend their time reviewing my code? What is their motivation?

[1] https://github.com/tensorflow/tensorflow/issues/22926#issuecomment-2888463504

5 comments

[ 2.9 ms ] story [ 18.4 ms ] thread
PaulHoule
It’s an investment in the future. You might become a useful contributor and maybe lead a project someday and have the chance to pay it forward.
acemarke
Because that's the responsibility we've placed on ourselves :)

I actually did a recent conference talk called "Maintaining a Library and a Community" where I discussed how being an OSS maintainer is really about communicating with your users and contributors, more than it is about writing code yourself. And yes, a big part of that is responding to issues _and_ reviewing externally-contributed PRs:

- https://blog.isquaredsoftware.com/2024/11/presentations-main...

I also even just tweeted over the weekend about how a user filed a PR to add a good new option to one of my libraries, but I still had to take time to review it, figure out what additional functionality should be added, then add tests and docs:

- https://bsky.app/profile/acemarke.dev/post/3m6defzgvcl2n

mgerdts
I’ve had many very kind people help me throughout my life. In most cases there was no clear immediate reward for them. Maybe there was immediate return - joy in sharing one’s craft or the satisfaction of passing on good will they received sometime long ago.

Every meaningful project I’ve worked on has benefited more from inclusion than exclusion. The person I help may or may not become a significant contributor to my project, but many times they become the person that can help me with something I’m learning. And so what if I never run across that person again? Maybe they will remember the kindness they received and pass it along.

gus_massa
I don't like "good first issues" If it's simple enough to be the first, I'd fix it in less time than writing an explanation of the problem.

Anyway, when someone makes a post about a typo in the docs or error message of Racket, or something that can be solved editing one or two files, I like to post something like:

> Nice report. The error is in the file [whatever]. Do you want to fix it and send a pull request? Otherwise we can fix it.

Some people want to contribute and are happy with that. It's a good first step. They may send something more complicated later. Or just be happy to have a commit merged. (Anyway, good bugs reports are very useful, even if the submitter does not fix it.)

As a general recommendation, start with tiny changes. Fixing typos is good because they must be fixed. For features, it's better let's say up to 6 hours of work. You never know if they are going to merge it, so it's better to waste few time. Later, once you have a few contributions try longer tasks.