I have been using small upstream PRs as a forcing function for proof.
Not big rewrites. Not "I built a platform" posts. Just narrow bugs in real repositories, with a test, a focused patch, and whatever cleanup the maintainer asks for.
That has been more useful than I expected.
The main reason is that a merged PR carries constraints a portfolio project usually does not. You have to fit the repo's style. You have to reproduce the issue. You have to keep the diff small enough for someone else to review. If the maintainer asks for a different shape, the answer is not to argue with your original idea. The answer is to understand the invariant they are protecting.
The fixes that taught me the most were not flashy:
- a React Router nonce fix for default SSR fallback/error scripts
- an
eslint-plugin-importfix that reported the runtime package name instead of@types/* - an ast-grep fix that rejected root multi-metavariable patterns at pattern creation
- an
eslint-plugin-regexpfix aroundmatchAll().toArray()capture-group usage - a
react-jsonschema-formfix for nested defaults through conditionalallOfschemas - an
eslint-plugin-playwrightoptional-chaining fix inmissing-playwright-await - a
knipreporter fix that always prints single-group titles and counts
None of those sound like a launch. That is the point.
They are small enough that the hard part is not architecture theater. The hard part is proving the exact behavior, avoiding unrelated churn, and making the change obvious to someone who has to maintain the project after you leave.
My current ledger is 25 merged upstream PRs, with more still open. The number matters less than the shape: real maintainers, real review, real constraints.
For paid work, I trust that signal more than a polished demo. A demo shows what I can build when I own the whole frame. A merged upstream PR shows whether I can enter someone else's frame, fix one thing, and leave the codebase easier to maintain.
Disclosure: I used AI assistance to organize this private article draft. The OSS examples and counts should be rechecked against the contribution ledger before publishing.
Top comments (0)