How to Get Your First Open Source PR Merged: 7 Lessons From 22 Google ADK PRs

Your first pull request rarely fails because the code is wrong. It fails because it is expensive to trust: a sprawling diff, no proof the bug exists, a style the repo does not use. I now have twenty-two merged PRs in google/adk-docs and thirty-two across four organizations, and the pattern is consistent — maintainers do not merge you because you are new; they merge you because your PR is cheap to verify. Seven lessons, in the order you will need them.

My examples are documentation PRs for Google’s agent framework — every PR and diff is on my open source page, and the full bug-pattern write-up is in this post. The mechanics below apply to code PRs the same way — I have just run them two dozen times in public.

1. Pick a repo where you are already a user

You will not find real bugs in a project you do not run. Choose the docs or code of a tool you already use daily, where breakage annoys you personally — that annoyance is free motivation and free domain knowledge. Before forking anything, read the contribution guide and ten recently merged PRs. The guide is the contract; the recent PRs are the accent.

2. Reproduce first, write second

Every durable PR starts the same way: “here is the failing case, here is the fix.” Run the snippet, paste the actual error, then change the minimum. My earliest merges — async session bugs in runnable examples, like PR #2051 — moved quickly because a reviewer could reproduce the failure in one command. No speculation, no essay: error, then fix.

3. One concern per PR

Bundling a fix with a refactor is how a PR sits reviewable for weeks. Split them: the broken link gets its own PR, the rename gets another. My smallest merge was a one-line link fix — it went in fast because there was nothing to debate. Reviewers approve what they can hold in their head at once.

4. Match the repo’s mechanics

Title format, license headers, formatting, file layout — every repo has opinions, and violating them turns a two-minute review into a style conversation. A Python snippet missing the Apache header cost a maintainer a round-trip once; the fix was +42 lines that touched nothing else. Checklist before you request review: guide followed, headers present, formatter run, docs build if the repo builds docs.

5. Make the diff boring

Reviewers read diffs for risk, and noise is risk. Reformatting nearby code, renaming variables you did not need to touch, shuffling imports wholesale — each line of unrelated change is a reason to slow down. Touch what is broken, nothing adjacent. A diff where every line obviously belongs to the stated problem is a diff that gets approved.

6. Review is a conversation, not a verdict

A maintainer’s comment means engagement, not rejection — respond the same day when you can, make the change, say what you changed. Revisions are how trust gets built; every one of my merged PRs carried a maintainer approval before landing, and the back-and-forth is exactly why that approval means something. Silence is the real enemy. A review thread is progress.

7. Momentum compounds

The first merge is the slowest by far. After a few, your name is familiar and the review muscle memory exists — four of mine merged on the same day, September 11, 2026, and thirteen more landed across two days in October. That is not talent compounding; it is trust compounding. So do not stop at one: open the next small PR while the first is still in review.

Nobody merges you because you are new. They merge you because your PR is cheap to trust.

Start this week

• List three tools you use daily, find their docs or code repo, and run one example from it.
• Read CONTRIBUTING plus ten recent merged PRs — title style, typical size, tone of the threads.
• Fix what you actually broke, reproduction attached to the PR description, diff as small as honesty allows.
• Then do it again next week. One small merged PR beats five ambitious drafts.

Want a second pair of hands?

If you are building with agent frameworks and want someone who spends his days inside other people’s review processes — let’s talk. And if you want the receipts first: every PR, status, and diff is on the open source page.