This week I got eight pull requests merged into three projects I didn't build: LightRAG, Tabularis and React95.
None of them are huge. The biggest is around 300 lines. The smallest is literally four. But every one of them got reviewed by the people who run those projects, and they said yes.
From the outside, open source can look like a closed club where you need to be some kind of genius to get in. It's not. It's mostly about being careful, and making it really easy for a busy person to say yes to you. Here's what that looked like in practice.
The loop at the bottom is where most of the time actually goes.
Start by reading, not by coding
My two LightRAG fixes didn't come from an issue. Nobody had filed a ticket. I was just reading the code that cleans up names the AI pulls out of documents, and noticed it handled <br> and <br/>, but not <br />. Same tag, one extra space.
That one space meant the same company could end up in the knowledge graph twice, once as AcmeCorp and once as Acme<br />Corp. You only find stuff like that by reading slowly, the way you'd read something you're about to be tested on.
The other way in is an issue that's been sitting there for a while. On React95, someone had already started fixing an accessibility problem, and their PR got closed after going stale waiting on a rebase. I picked it up, finished it, and said so in the description. That's one less half-done thing sitting in their repo.
One PR, one thing
If I had to give one rule, it's this.
Every PR I sent fixes exactly one problem. Not "fixed the bug, and also cleaned up some formatting while I was in there." Just the bug. The LightRAG fixes are around 55 lines each, test included.
Small PRs get merged because they're easy to say yes to. A maintainer can read one on their phone, get it in two minutes, and hit merge. A PR that touches ten things is homework, and nobody wants homework from a stranger.
Show the bug, don't explain it
The most useful thing I did in my PR descriptions was add a tiny before-and-after table.
For the LightRAG one it was three rows: what the AI wrote, what the entity name became on main, and what it becomes with the fix. You look at it for five seconds and you get it.
Same idea in Tabularis. I noticed that a DELETE tucked inside a WITH clause would run without the usual "are you sure?" prompt, because the editor only looked at the last keyword, which here is SELECT. So I just put the query in the description:
WITH gone AS (DELETE FROM users RETURNING *)
SELECT count(*) FROM gone;
Anyone who's ever worked with a database looks at that and goes "oh no." That's the reaction you want before they've even opened the code.
Do the boring parts too
The part that isn't the fix is half the work, and it's what tells a maintainer you can be trusted with their codebase:
- Tests. Almost every PR came with a test that fails before the fix and passes after.
- Their rules, not mine. Tabularis supports 13 languages, so my new buttons got text in all 13 files. On React95, I labeled one change so it wouldn't trigger a new release of their package, because it only touched the docs.
- Say what you ran. I started adding a short "What I ran" section: which tests, which checks, what failed before and passed after. It saves the reviewer from wondering if I even tried it.
Review is a conversation, not a grade
My Tabularis DELETE fix went through six reviews. Six. At first that feels like you got something wrong. But each round made it tighter, and none of it was about rejecting the idea. It was about getting it right.
So I answered every comment, fixed what was asked, and didn't argue about style. It's their project. I'm a guest.
If you want to start
Pick a project you actually use. Read the part of the code you've always been curious about. When something looks off, write the smallest fix you can, add a test, and show the before and after.
That's honestly it. No secret trick. Just care, and make it easy for someone to say yes.
Every PR I've had merged is on my open source page. It updates itself whenever a new one lands.
Sources
- LightRAG #4384: strip
<br />and<p />from extracted names - LightRAG #4385: keep merged DOCX table cells once
- Tabularis #1451: confirm a
DELETEorUPDATEinside a CTE before running it - Tabularis #1452: edit text stored in a BLOB as text
- React95 #609: the accessibility fix I picked up from a stale PR
- React95 #614: make the Start menu usable from the keyboard