Rung 7 — Merged OSS PR + Technical Blog Post¶

Headline. At least one merged (not just opened) non-trivial pull request to a top-tier C project, plus a technical blog post about a specific lesson from the journey — the proof that you can ship code alongside experienced maintainers.

Month target. M13 (July 2027). The PR must be merged by the last day of M13; opened but not merged does not count.

What You Build¶

There is no “repo you create” for Rung 7. The artifact is someone else’s repo, with your commit inside it, plus your writeup around it. This inversion is the whole point of the rung: for the first time, mastery is measured by whether strangers with commit access accepted your work.

Target project shortlist (pick ONE primary, keep TWO backups):

Project	Why it fits	Difficulty	Typical PR size
redis / valkey	Widely used, active maintainers, many `good first issue` labels	Medium	100-500 LOC
curl	Very active, welcoming to newcomers, huge issue backlog	Medium	50-300 LOC
llama.cpp / ggml	Directly monetizes Rung 6; SIMD PRs land here	Medium-Hard	100-800 LOC
nginx	Prestige, but review latency can be months	Hard	100-400 LOC
sqlite	Extraordinary quality bar; Richard Hipp reviews personally	Very Hard	20-100 LOC
ClickHouse	Mostly C++; only pick if a C-adjacent module has an open issue you can own	Hard	Varies
Neon (PostgreSQL fork)	C postgres extensions; fewer reviewers, faster merges	Medium	50-300 LOC
TigerBeetle	Zig-first, but has C bindings; niche and prestigious	Hard	Varies
tinygrad-adjacent (ggml, mlx-c)	ML infra credibility	Medium-Hard	Varies

What counts as “non-trivial”:

≥ 200 LOC changed OR a smaller diff that is demonstrably significant (fixes a known-hard bug, adds a documented feature, improves a benchmark by a measurable amount).
Documentation-only PRs do NOT count for Rung 7 (they can count as warmup PRs and are encouraged — but the graduation PR must be code).
Typo fixes explicitly do not count.

The blog post:

≥ 1500 words, on your personal blog + dev.to.
Structure: (1) how you found the issue, (2) how you understood the codebase’s conventions, (3) the technical content of the change, (4) the review round-trip — what feedback you got and how you incorporated it, (5) the lesson you’d apply to your next PR.
Code snippets from the diff, with permalinks to the merged PR.
Honest about the pain: how many hours reading the code before you touched anything, how many review rounds, what almost got you rejected.

Why This Rung, Why Now¶

Rungs 1-6 all live on your GitHub. A skeptical hiring manager could still argue that you have curated your own work into a favorable narrative. Rung 7 is the rung where a maintainer you did not choose stamped your code as acceptable. That stamp is not fakeable.

You ship in M13 because M12 is the reconnaissance month — you spend 4 weeks reading a target codebase, filing 2-3 warmup issues, opening 1-2 typo/doc PRs to learn the review workflow, and finding your real target issue. Rushing this earlier means opening PRs on code you don’t understand, which wastes maintainer time and burns the relationship.

Acceptance Criteria¶

PR is merged (status: merged, not closed/open) on master/main of the target project
Diff is ≥ 200 LOC changed OR has explicit maintainer acknowledgment of significance (a review comment saying “this is a meaningful fix”, a mention in release notes)
PR passed the project’s CI
You engaged with review feedback in ≥ 2 round-trips (not a one-shot merge, which usually means the PR was trivial)
Blog post ≥ 1500 words published on personal blog + dev.to
Blog post links directly to the merged PR (permalink, not just repo)
LinkedIn post announcing the PR merger — this is the post that closes your 13-month arc
Optional but recommended: HN Show HN submission of the blog post if the technical content is dense enough

Where to Publish¶

The PR page itself — this is inherently public and permanently linkable. It is your primary artifact.
Personal blog + dev.to + Hashnode: the writeup.
Hacker News: submit the writeup if the technical content is deep. Do not submit “I got a PR merged” — HN doesn’t care. Submit “How I traced a race condition in Redis’s replication path and fixed it” — HN loves that.
Reddit — r/programming: cross-post the writeup.
Reddit — the project’s community subreddit if it has one (r/redis, r/rust doesn’t apply here, r/PostgreSQL for Neon, etc.).
LinkedIn: the closing post of the 13-month journey. Include: which project, what the change was in one sentence, PR link, blog link, one honest reflection on what changed in your engineering habits between M1 and M13.
Your GitHub profile README: update PORTFOLIO.md with this rung linked at the top.

Signal to Recruiter / Employer¶

“This person ships code alongside experienced maintainers. Their code has been reviewed by people whose full-time job is that codebase, and it was accepted. They are hireable at senior-adjacent systems roles. If we hire them, they will not need three months to be productive in an unfamiliar C codebase — they’ve already demonstrated the meta-skill of learning a codebase.”

Rung 7 is the closing signal. Combined with Rung 6 (ML-infra credibility) and Rung 5 (systems-programming credibility), your public identity by M13 is “person who ships C in production adjacent to an inference engine” — which is exactly the identity the M13 pitch sentence claims.

Common Failure Modes¶

Opened, never merged. You open a PR in M13 and it sits in review through M14. Detection & mitigation: file the PR by mid-M13 at latest; if the target project’s median review latency exceeds 30 days, choose a different target. redis, curl, llama.cpp all have < 14-day median review turnaround for small-medium PRs.
Trivial PR labeled non-trivial. A 20-line fix to a typo in a comment. Detection: the acceptance criterion is 200+ LOC OR explicit maintainer significance acknowledgment. A README fix fails both.
Fork without upstream engagement. You add a feature to your fork and never open the PR. Detection: the artifact is the merged PR, not your fork. No PR = no rung.
Blog post that is bragging, not teaching. “I got merged into Redis!” is a signal for you, not for the reader. The blog post must teach how you did it so the reader could imitate the process.
The abandoned first PR. You pick sqlite as your target, spend a month, get rejected, and give up. Mitigation: the shortlist above has THREE tiers of difficulty. Start reconnaissance on your primary target and one backup in M12. If the primary stalls, pivot in early M13.
Skipping the warmup PRs. You go straight for the ambitious PR without earning maintainer familiarity. Mitigation: open 1-2 tiny, low-controversy PRs first (a compiler warning fix, a small doc improvement). These teach you the project’s PR etiquette and put your name in front of reviewers.

Estimated Hours¶

Reconnaissance (M12): reading target codebase, filing warmup PRs, finding real issue — ~30h
Solution design + implementation: ~25-40h (varies wildly by project)
Review round-trips: ~10-20h (2-4 rounds × 3-5h each)
Blog post: ~15h
Announcement posts + polish: ~5h

Total: ~85-110 hours across M12-M13. ~11-14h/week for 8 weeks. Comparable to Rung 5’s load; the variance is higher because you don’t control the review timeline.

Prior-Art / Inspirations to Study First¶

Julia Evans’ “How to contribute to open source” posts — the mindset pieces. Read before you touch a target repo.
The CONTRIBUTING.md of your top-3 target projects — read them all in M11 so you know which project matches your temperament.
The last 20 merged PRs on your target project — study what got merged, by whom, after how many rounds. This is your calibration data.
Antirez’s (Salvatore Sanfilippo) old blog posts on Redis maintainership — the maintainer’s-eye view. Understand what a maintainer optimizes for and you become 10x easier to review.
“How to make a good pull request” — GitHub blog, Kent C. Dodds, or similar — the mechanical hygiene: small commits, clear commit messages, one concern per PR.

Return to README.md · Previous: 06_rung_6_simd_gemm_benchmark.md · Next: 08_hard_gates_and_signals.md