Rung 6 — The First Merged PR

Aligned phase: Phase 6 (community + OSS contribution) Ship by: first PR merged by end of M9. Three PRs merged by end of M12. Effort: ~40 hrs spread across M8–M12. The wait-for-review time dominates the wall clock; the code time is small. Signal: the single highest-leverage line on your resume. A merged commit URL to vllm-project/vllm or sgl-project/sglang outweighs any blog post you will ever write. This is the credential.

Why this rung is the credential

Every previous rung was you talking about the field. This rung is the field talking back. A merged PR is a public, timestamped, adversarially-reviewed proof that:

  1. You read the code base well enough to change it correctly.

  2. Your commit met a real maintainer’s bar for style, testing, and design.

  3. You can operate inside a project’s culture — DCO, CI, review cycles, follow-ups.

Recruiters filter on this. Hiring committees weight it. Founders DM about it. It is worth more than the previous five rungs combined for credential purposes. It is worth less than them for skill purposes — you cannot earn a merged PR without those rungs first. That’s the point.

The canonical first-PR path — do these four in order, no skipping

1. USE       →  Run the engine on your own workload for at least a week.
2. BENCHMARK →  Reproduce an official benchmark. Beat it or fail to and explain why.
3. ISSUE     →  File one great issue that includes a repro, environment, and hypothesis.
4. FIX       →  Send one small PR that closes something on the tracker.

Do not skip steps 1–3. The people who skip to step 4 land drive-by PRs that get closed with “please read CONTRIBUTING.md first” and never come back. The three rungs of context before the fix are what make the fix land.

Step 1 — Use (2 weeks)

  • Deploy vLLM (or SGLang) on your rung-4 quantized model. Serve it. Load-test it. Break it.

  • Read the CHANGELOG for the last two minor releases end-to-end. Note every feature you don’t understand — those are your later PR targets.

  • Read CONTRIBUTING.md, SECURITY.md, and the governance doc (vLLM: docs/contributing/; SGLang: docs/developer/; llama.cpp: CONTRIBUTING.md + issue templates).

Step 2 — Benchmark (1 week)

  • Reproduce one published benchmark from a release blog or paper. Same hardware class if possible; note the delta if not.

  • Publish your reproduction as a gist or a comment on the release-notes discussion thread. This is your first named appearance on the project’s public surface. It is not a PR; it is a receipt.

Step 3 — File one great issue (1 week)

The anatomy of a great issue (steal this template):

### Environment
vllm 0.7.3, CUDA 12.4, PyTorch 2.5.1, H100 80GB SXM, driver 550.90.07,
model = <exact HF revision SHA>, launch flags = <full command>

### What I ran
[reproducible commands]

### What I expected
[SLO or documented behavior]

### What I observed
[numbers + logs + Prometheus snapshot if applicable]

### Hypothesis
[one paragraph. Reference specific files/lines you read.]

### Ready to send a PR against
`vllm/v1/core/scheduler.py:412` — happy to open a draft if this is the right place.

A great issue is one a maintainer can act on in <5 minutes. Environment + exact repro + hypothesis + offer to fix. Issues without these get closed with a template reply. Issues with these get a maintainer’s @ on the first pass.

Step 4 — Send one small PR

Small = <200 lines diff, ≤3 files touched, one bullet in the release notes. Larger first PRs almost never merge — reviewers don’t have the context on you yet.

Concrete first-PR ideas — pick one, do not brainstorm more

Ranked easiest → hardest. Do the easiest one that isn’t already taken.

  1. Doc fix. A wrong flag name, a stale example, a broken link, a missing environment variable in the README. Nearly guaranteed merge. Not resume-worthy by itself, but it gets you an author line and a Contributor badge, and it teaches you the review cycle.

  2. Kernel micro-benchmark script. Add benchmarks/kernels/bench_paged_attention_your_variant.py. Follow the exact style of the existing scripts. This gets merged because it doesn’t touch runtime code. This is the sweet spot for your first substantive PR.

  3. Add a new Prometheus metric to the /metrics endpoint. For example, a histogram of prefix-cache lookup latency, or a counter for chunked-prefill splits. Look at vllm/v1/metrics/loggers.py for the pattern. Small diff, high user value, easy to review.

  4. A small chunked-prefill edge case. Off-by-one when the last chunk equals chunk_size, or a scheduler bug when a request arrives during a prefill split. These exist. Grep the issue tracker for “chunked prefill” + bug.

  5. GGUF metadata fix in llama.cpp. A missing key in convert_hf_to_gguf.py for a newly supported model, or a wrong tensor name mapping. High merge rate, but the llama.cpp maintainers are terse; do not take a review comment personally.

  6. EAGLE / MEDUSA draft-model integration test. Add a test that exercises the speculative-decoding path on a small model in CI. Requires actually understanding spec-decoding, so it doubles as a Phase 4 study exit.

  7. A good first issue labeled task. Filter → oldest → still open → ask on the issue “is this still wanted? I’d like to take it.” Wait 48 hours for a maintainer reply. This is the highest-hit-rate path but you must wait for the ack.

Explicit non-starter first PRs: performance improvements to hot-path kernels, scheduler policy changes, new sampler implementations, anything touching CUDA graphs. These are second-PR territory. First PRs that touch hot paths almost never merge — the reviewers don’t have signal on you yet.

Where to send them — one target project, not four

Pick one and stay for at least three PRs. Splitting attention across projects makes you a stranger in each.

Project

When to pick it

Contributor culture

vLLM

Default choice. Largest surface area, largest hiring pull, largest issue backlog.

Fast reviews, high bar, active Slack (#dev).

SGLang

If your interest is RadixAttention / structured outputs / router.

Smaller team, warmer culture, review latency variable.

llama.cpp

If your interest is quantization / edge / heterogeneous.

Terse. High technical bar. GGUF format is theirs.

FlashInfer

If your interest is kernels.

Very small maintainer set. High signal per PR.

Prescription: vLLM as your primary target. It is the highest-signal project for the specific inference-engineer role you are aiming at. Zoho’s stack, when it goes on-prem, is more likely to end up on vLLM than on SGLang. Rung 8 lives there too. Optimize the whole ladder around one project.

Maintainers to know by name (do not @ them casually)

vLLM:

  • Woosuk Kwon (WoosukKwon) — original author, V1 engine architect.

  • Zhuohan Li (zhuohan123) — co-author.

  • Youkai Chao (youkaichao) — CUDA graph + torch.compile + backend.

  • Simon Mo (simon-mo) — release management + community.

  • Nick Hill (njhill) — API server + async paths.

  • Michael Goin (mgoin) — quantization / Neural Magic → RH.

SGLang:

  • Lianmin Zheng (merrymercy) — co-author, prof at CMU.

  • Ying Sheng (Ying1123) — co-author, RadixAttention.

FlashInfer:

  • Zihao Ye (yzh119) — author.

llama.cpp:

  • Georgi Gerganov (ggerganov) — author.

  • Iwan Kawrakow (ikawrakow) — k-quants.

  • Diego Devesa (slaren) — GPU backends.

  • Xuan-Son Nguyen (ngxson) — HF integration.

Rule: you may @ a maintainer only when they have already touched the file you are changing (via git blame) or when their handle appears in a CODEOWNERS. Never @ them to attract eyeballs to your PR. That is the fastest way to get quietly de-prioritized.

The behavior norms — non-negotiable

  1. Sign the DCO on every commit. git commit -s. vLLM enforces this via a bot; SGLang expects it. If your first PR fails the DCO check, you look like a stranger. Configure git config --global user.email <the email on your GitHub account> and set git config --global commit.gpgsign true if the project requires it.

  2. Read CONTRIBUTING.md end-to-end before you push. Not skim. Read.

  3. Pin every benchmark to a released version, not main. pip install vllm==0.7.3, not pip install git+...@main. Benchmarks against main are unreviewable because main moves; benchmarks against v0.7.3 are citable.

  4. One PR, one concern. Do not bundle a doc fix with a metric addition. Do not sneak a refactor into a bug fix. Reviewers close PRs with mixed concerns without reading them.

  5. Include a reproducible script for perf claims. Not a table in the PR body — an actual benchmarks/ script. simon-mo and WoosukKwon will ask for it if you don’t include it; save the round trip.

  6. Respond to review comments within 48 hours. If you can’t, comment “traveling this week, will reply Sunday.” Silence is what kills PRs. The review-latency budget is measured in your responsiveness, not the maintainer’s.

  7. Do not force-push after review starts. Add commits. The reviewer’s line comments break under force-push and the review restarts. Squash at the end, only after the maintainer says so.

  8. Never argue in the PR thread. If you disagree with a review comment, ask a question. “Would a follow-up PR be a better shape for X?” always beats “I don’t think we need to do X.”

  9. Write the release-notes line yourself. Most maintainers appreciate a one-liner in the PR body: Release notes: Added histogram metric for prefix-cache lookup latency.

What signals it sends

  • “I can navigate a codebase with 100k+ LOC and land a change without breaking it.”

  • “I understand this project’s conventions well enough that a maintainer trusts me.”

  • “I am the kind of engineer who ships small, verified diffs, not big untestable proposals.”

  • “I have skin in the game on OSS, not just as a consumer.”

The commit URL — github.com/vllm-project/vllm/commit/<sha> · authored by <you> — is the resume line. Put it on your resume. Put it on LinkedIn. Put it in your email signature for two weeks.

The Zoho angle (real, not manufactured)

If your first PR touches prefix caching, the write-up around it should mention: “Motivated by measuring hit rates on an internal agent workload at Zoho — 83%/91%/94% on turns 2/3/4.” That single sentence turns your PR from “student contribution” into “practitioner-authored.” It also lays the ground for rung 8 in the same subsystem.

Do not name any customer, product surface, or internal tool. The workload shape is what earns the credit. Get your manager’s sign-off before referencing Zoho in an OSS PR write-up; the ask is small and the paper trail is worth it.

Past examples to study (read these three PRs end-to-end before opening yours)

  • Any PR by @njhill with a diff <150 lines to vllm/entrypoints/openai/* — the canonical example of a clean, focused server-side PR with tests.

  • Any PR by @mgoin adding a quantization method — reads like the template for “add a feature to an existing subsystem.”

  • Any good first issue closed by an outside contributor in the last 6 months on vLLM. Read the issue, the PR, the review, the merge. That is the exact loop you are entering.

  • The SGLang router PR series by @Ying1123 — the shape of a substantial contribution rolled out over ~6 PRs. Study the sequencing more than the code.

Read three PRs. Not thirty. Depth beats breadth here.

Common mistakes

  1. First PR too big. 500-line diff, 8 files touched, “this refactors the scheduler.” Closed with “let’s break this up.” You cannot come back easily. Cap first PR at 200 lines.

  2. First PR to hot path. Touching paged_attention kernels or Scheduler.schedule() on your first PR. Reviewers do not have your signal yet. Save hot-path changes for PR #3+.

  3. @-ing maintainers to hurry the review. Never. Wait. If a PR has been open >2 weeks with no review, comment “friendly ping — happy to rebase or split if useful.”

  4. DCO check failing on first push. Look like a bot. Configure git config commit.gpgsign and -s before the first commit.

  5. Benchmarks against main. Not reproducible; reviewers ask you to redo them; the PR sits. Pin to a release.

  6. Silence after review comments. Two weeks of no reply and the PR is stale. Reviewers move on. Reply within 48 hours or say why you can’t.

  7. Bundling doc + code + refactor in one PR. Rejected without a full read.

  8. Not running the project’s own tests locally. pytest tests/ before pushing. CI failure on your first PR looks careless.

  9. Trying to “impress” in the PR description. The PR description should be boring: what, why, how tested. The commit is the impressive part.

Success criteria checklist

  • Ran vLLM (or chosen project) on your own workload for 2+ weeks

  • Reproduced one official benchmark and posted the results publicly

  • Filed 1+ high-quality issue with environment, repro, and hypothesis

  • Read CONTRIBUTING.md, DCO policy, and CODEOWNERS end-to-end

  • DCO configured and working on first push

  • First PR ≤200 lines, ≤3 files, single concern

  • Local pytest passes before pushing

  • Response time to review comments <48 hours across the PR lifecycle

  • One merged commit by end of M9 — this is the gate

  • Three merged commits by end of M12 — this qualifies you for rung 8

Timing math — the reason to start rung 6 early

Median vLLM PR merge time for outside contributors: ~14 days. Range: 3 days to 3 months. Your first PR will be on the longer side because maintainers are calibrating on you. If you want a merged PR by M9, open the first draft by M8 week 3. Rung 5 finishes at end of M8 by design — that is the handoff. Do not treat rung 6 as sequential-only; overlap it with rung 5’s final weeks.

Success signals (measure at 3 months of activity)

  • 1 merged PR by end of M9

  • 3+ merged PRs by end of M12

  • Named on a release notes entry

  • A maintainer has @-ed you asking about a follow-up

  • You get pinged on an issue in the area of your first PR because “this looks like something you’d know”

The last signal — being pinged on issues — is when rung 6 turns into rung 8. That is the beginning of ownership.

Next step

On the Monday after your first PR merges, you open the issues page of the same project, filter to the subsystem your PR touched, sort by oldest-open, and pick the second target. Post a comment on that issue: “I recently landed . Happy to look at this one next — will start reproducing tomorrow.” That comment is how the maintainer starts remembering your name. Rung 6 is not “one merged PR.” Rung 6 is becoming a name the maintainers know. One PR is the ticket; ten is the ID card.

The ladder is the CV. Every rung is public. Every rung compounds.