Skip to content
All posts
2 min read

Contributing to Google's ADK Docs: 22 Merged PRs, What I Learned

Twenty-two maintainer-approved PRs merged into google/adk-docs in three months — the bug pattern behind most of them, and how to start contributing to agent docs.

Developer reviewing code on a tablet in a modern office

Google's Agent Development Kit (ADK) has an official documentation site, google/adk-docs, where every code sample is something a developer will copy, paste, and run late at night. Between July and October 2026, twenty-two of my pull requests were merged into that repository — and every one of them was approved by a maintainer. Here is what they fixed, and the pattern behind most of them.

What the first nine PRs fixed

They fall into four buckets:

  • Async bugs in runnable examples: a doc_analysis snippet whose process_document had to be async, plus agent_search and agent_cli examples that did not await create_session — PR #2051, #2053, and #2055.
  • Dead links and rotted imports: a broken MCP link in the temporal integration guide and a broken relative import in the rag_engine example — PR #2307 and #2052.
  • License headers: the Python snippets were missing Apache 2.0 headers. A +42-line change that touched nothing else — PR #2054.
  • Precision fixes: typos in the prose, a wrong version-requirement note in the live tools doc, and a route-key mismatch in the conditional-routing workflow example that would misroute conversation turns — #2311, #2313, and #1996.

The pattern behind most of them

Docs examples are code that almost nobody runs in CI. The source evolves, the snippets drift, and the copy-paste user eats the first-run failure. Three of my first nine PRs were the same class of bug: a session API became async and the examples never caught up. On a docs site the example is the product — a broken one costs trust before the reader writes a single line of their own.

How I find these — a repeatable loop

  1. Read the docs like a reviewer, not a reader: run every snippet you touch.
  2. Compare each call against the current SDK source instead of trusting the prose.
  3. Keep the diff minimal — one concern per PR, nothing bundled.
  4. Follow the repository's contribution guide: title format, small verified changes.
  5. Reproduce the bug first, then write the fix.

Small, verified PRs move fast

Four of my earliest merged on the same day — September 11, 2026 — and three more on October 5; thirteen more landed October 15–16, 2026. The smallest was a one-line link fix. Docs maintainers merge what is easy to verify, and a PR that shows the failing case first is easy to verify.

Why it matters beyond the docs

Across four organizations — OpenAI, Google, OpenClaw, and n8n — I have had 32 pull requests merged so far; every PR, status, and diff link lives on my open source page. Contributing upstream forces you to read other people's code and survive other people's review. Both show up in client work: agent frameworks, integrations, and automation are what I build with daily.

If you are starting out: pick the docs repo you already read, run the snippets, and fix what breaks. And if you are building with agent frameworks and want a second pair of hands, let's talk.

Gallery

Related posts