Thread by @dan_abramov

How do open source maintainers pick which contributors to “invest” in (time, effort, mentorship, etc)? I don’t know about others but for me the main thing isn’t coding skill. The main thing I’m looking for in a contributor is good judgement. This concept may sound fuzzy… 🧵

First, what good judgement is NOT. It has nothing to do with where you’re from, how you present yourself, how old you are, or even how many years of professional experience you have.

Good judgement also has nothing to do with the “clout” or being known. There are people with 5 followers whose judgment I would trust more than well-known characters with latge audiences.

So what do I mean by “good judgment”? I can’t give a precise definition but I’ll describe what working with a person like this feels like.

Reading their PR descriptions is a treat. They use the right amount of detail — not paraphrasing the code but enough to explain what they’re doing, how, and most importantly, *why*. They mention their thought process — why this approach, alternatives rejected, how they tested.

They look at a bigger picture. For example, if there is a crash, they don’t just add != null check on the line that crashes. They look at *why* that thing is null, whether it’s supposed to ever be null or not, where the assumptions were violated, and what’s a good place to fix.

They don’t look at code as a static “here’s what the computer runs” level. They see a living body of work. They try to figure out the past intentions (of the people who wrote it), track the history of changes (where was a mistake introduced?), leave breadcrumbs for next readers.

They look at the result end-to-end. If they fix a bug, they don’t rely on “tests pass” as the only signal. They put it in a project that reproduces the bug, and verify that the bug is gone. (Here’s a secret: if you don’t do this, the maintainer says thanks but does it for you.)

They maintain quality. They put in equal amount of work in verifying their change is right and works as intended as into the change itself. It’s noticeable they CARE. They act as a merciless QA for their own work — not shying away from spending hours on meaningful testing.

When I see “I tested on three resolutions in three browsers and went through scenarios X, Y and Z” (or equivalent that makes sense for the project) my heart fills with joy. This person knows I’ll have to do this anyway and they’ve shown the courtesy of doing it first. Thanks.

This doesn’t mean they can’t screw up. All of us can! But they take enough diligence that the mistakes feel earned. There’s a difference between something slipping through and literally not bothering to chrck whether the change does the thing. Be your own QA and I’ll trust you.

This might sound ungrateful, but in many cases the maintainer helping *you* — to land a commit in a popular project, to have a good contributing experience, etc. Often, they can do an equivalent change fast but they want it to be yours and spend days on back-and-forth.

They are very perceptibe to the context. Beyond following the guidelines, they try their best to infer the things that may not be directly visible — assumptions, project aspirations, quality bar, tech debt areas, frustrating workflows, intentionally cut corners, style, vibes.

They see the end result as a holistic product. They look at their change in the context of the goals of the project, other people’s issues, other solutions. They act as if they are responsible for the whole thing—even if at the moment they only change a small part.

Responsibility is central to this. Most contributions—while great—need maintainers to add more responsibility to their plates. Test this change, figure out how this code worked before, research browser differences, etc. But there are some contributors who *take* responsibility.

They look for opportunities and propose meaningful changes. Changes that are scoped, pragmatic, usually incremental. Their changes “feel” more like “carving out” what should be “already there” rather than attaching something extra. They make the $PROJECT feel more $PROJECT-y.

There is no ego in their work. It’s clear they’re not *just* sending it to build up a resume. Their priority is to land the right change for the project (and figure out what it is!) rather than to land their exact idea. They might send *simple* changes but not spammy ones.

So far I’ve focused on the code (although the same applies to documentation too). However, they are usually active beyond that. In fact, I usually see these people start *outside* code: helping people in issues, testing other PRs, making reproducing cases for bug reports.

This makes sense because for established projects, many valuable activities *are* external to code. There’s nothing wrong with wanting to score a PR, but it’s noticeable when a person has a more community/product-driven mindset, and takes some routine work off maintainers’ plate.

They show an interesting balance of cultivating a vision for the parts they’re interested in while staying genuinely curious and protective of the project’s oberall existing vision.

How does one learn this? I don’t know. I’ve seen people fresh out of bootcamp who excel at this and I’ve also seen people with 10+ years of experience who don’t. Empathy helps. If you can imagine what it’s like to be in maintainer’s shoes, you’ll soon be ready to be a maintainer.

A few people I’ve seen do this type of work recently: @sebsilbermann has been spectacularly helpful on the React repo and everywhere around (we don’t deserve him), @SylwiaVargas with new React Docs example content, @harishkumar_s_s helping with the new React Docs website.

I should clarify that there’s nothing wrong about simple drive-by PRs that do none of those things. (I send quite a few of those myself!) My thread is about how to stand out — these are the qualities I’ve observed in people who get invited to co-maintain in different projects.

At the end of the day, it’s open source. Reading this might make you think: “wtf, all this work and for free?” That’s fair. I wouldn’t expect any developer to *want* to do all of this. Some might want to but not have the time to do so much extra work either.

Still, the average bar is low enough that by putting in slightly more effort you can already stand out. Also, maybe don’t start with PRs to huge projects — often maintainers don’t have time at all. Smaller projects often have more actionable things to fix and faster review times.

Also, this isn’t to say that as a maintainer you should only help people who are already great at this. It’s a pleasure to help someone who is struggling to grow their skillset — when time allows. What I described is more about how people earn trust on projects in longterm.

I do want to emphasize though that none of this is about the *volume* of the work. (If anything, larger PRs are very rarely hitting that quality bar!) It’s about thoughtfulness and care noticeable in the approach. Even for small things.