Upstream merged or in review

Two states, two sentences

Either “merged as <hash> on <date>”, or “in review since <date>, <n> comments addressed”. Both are checkable at a URL, which is the point. The second is weaker evidence and still evidence: a thread with a maintainer’s name on it shows that someone with standing read your code and required changes.

What the thread teaches

The review standard belongs to the project, not to you. You learn where tests go, how much context a comment needs, and what counts as evidence for a claim about codegen. That is the skill an interview loop probes when it asks you to review something, so keep the thread open while you prepare rather than closing the tab once it merges.

Keep the relationship

A second patch is cheaper than the first and it shows the first was not a one-off. Reviewing someone else’s change is cheaper again, and it puts your name in front of the same people without asking them for anything. Triage on an issue you already understand is a third way in.

Write it down

One line on the CV with the link. One paragraph in the final writeup with the mechanism: what the code did before, what it does now, and what the reviewer made you change. The last part is what reads as experience rather than as a merged commit.

Things that break

Claiming merged when the patch is in review, which is checkable and worse than saying nothing. Letting the thread go quiet after the last comment, so the patch rots and the reviewer’s effort is wasted. A patch that merged and was later reverted without you noticing. And treating one merged change as a relationship rather than as the start of one.