I currently have 59 open PRs. 883 have been merged. 385 were closed without merge. These aren’t hypothetical numbers — they’re from my actual GitHub history as of today.

When I wrote my first post about open source contributions, I had maybe a dozen PRs to my name. Now I’m managing contributions across 16+ repositories simultaneously. The game looks completely different at this scale.

The Reality of Scale

On any given day, I might have active PRs in openclaw, hermes-agent, multica, NemoClaw, opencode, Archon, and half a dozen other projects. Each repo has different CI pipelines, different coding standards, different review cultures, and different merge timelines. Some repos want conventional commits; others don’t care. Some have strict linting; others have none at all.

Keeping all of that context in your head is impossible. I know because I tried. The first time I had 20+ open PRs, I’d forget which ones needed rebasing, which ones had review comments I hadn’t addressed, and which ones were just silently waiting in someone’s queue.

That’s when I realized: this isn’t a coding problem. It’s a systems problem.

Most Time Is Spent Waiting

Here’s the thing nobody tells you about contributing at scale: coding is the easy part. The hard part is the queue.

A typical PR lifecycle looks like this: I find an issue, read the codebase, write the fix, run tests, push, open the PR. That whole process might take 30 minutes. Then the PR sits in the review queue for three days. Or a week. Or longer.

Some maintainers are incredibly responsive — reviewing within hours, leaving thoughtful feedback, merging the same day. Others take weeks, and that’s completely fine. They’re volunteers with day jobs. But it means that at any given moment, most of my open PRs are in a state of waiting.

The worst thing you can do is wait with them.

Systems Beat Memory

With 50+ PRs in flight, you need automation. I can’t check each repo manually every morning — that would eat my entire day before I wrote a single line of code.

So I built patrol loops. Every morning at 2 AM, a cron workflow scans all my open PRs across every repo I contribute to. It checks:

  • Has CI passed or failed?
  • Are there new review comments I haven’t responded to?
  • Has the PR been approved but not merged?
  • Has the base branch moved ahead, requiring a rebase?

If something needs attention, it surfaces in my daily review. If everything’s green, I move on. The system watches so I don’t have to.

This is the lesson that took me longest to internalize: tracking work is itself work, and it deserves the same engineering rigor as the code. A spreadsheet in your head isn’t a system. An automated pipeline that checks status and raises alerts — that’s a system.

The 385 Closed PRs

Let’s talk about the number people usually avoid: 385 PRs closed without merge.

That’s roughly a 70% merge rate (883 merged out of 1,268 total). Is that good? I think so. Here’s why.

Not every PR should get merged. Some repos have strict CLA requirements I didn’t know about going in. Some PRs duplicated work that was already in progress on a different branch. Some got superseded by a better approach — sometimes mine, sometimes someone else’s. A few were just wrong, and the reviewer was right to reject them.

The closed-without-merge number isn’t a failure metric. It’s the cost of casting a wide net. If every single PR you open gets merged, you’re probably not taking enough chances. You’re staying in your comfort zone, only picking the safest, most obvious fixes.

I’d rather have a 70% merge rate across diverse, challenging contributions than a 100% rate on trivial typo fixes.

Parallel Work Is the Real Skill

This is the single biggest lesson from contributing at scale: while PR #1 waits for review in repo A, start PR #2 in repo B.

It sounds obvious, but the temptation to block on a single PR is real. You submitted what you think is a great fix. You want to see it through. You keep refreshing the page, willing the maintainer to review it. Meanwhile, hours pass and nothing else gets done.

I learned to always have 3-4 repos I can switch to. When I hit a wall in one place — waiting for review, blocked by a flaky CI, need clarification from a maintainer — I context-switch to another repo where I can make progress. The goal is to never have zero things moving forward.

It’s like an assembly line. You’re not building one car from start to finish. You’re tending 50 cars at different stages of production, moving each one forward when it’s ready for the next step.

The Blockers Nobody Warns You About

Not all blockers are human. Some are infrastructure.

Branch protection rules: NemoClaw is a good example. I’ve had PRs approved by reviewers but unable to merge because branch protection requires specific approvers or status checks that haven’t been configured. Five PRs sitting in approved-but-blocked limbo. Sometimes the blocker isn’t people — it’s the repo’s settings.

Pre-existing CI failures: In hermes-agent, some test suites have flaky or pre-existing failures that have nothing to do with your change. Your PR shows a red CI badge, but the failures existed before you touched anything. You still have to acknowledge this in the PR, explain which failures are yours and which aren’t, and sometimes wait for a maintainer to confirm.

Review ping etiquette: For Archon, I pinged the maintainer twice over four days. Too aggressive? Not aggressive enough? There’s no universal answer. Some maintainers appreciate the reminder; others find it annoying. I’ve learned to check the repo’s pulse — how often do they merge? How many other open PRs are there? — before deciding how long to wait before a gentle nudge.

What I’d Tell Myself Three Months Ago

If I could go back to when I was starting out, here’s what I’d say:

Build the tracking system on day one. Don’t wait until you’re drowning in open PRs. Start with a simple daily check: what’s open, what needs action, what’s blocked? Automate it as soon as you can.

Expect rejection. Not every PR will land, and that’s fine. The maintainer isn’t rejecting you — they’re rejecting a specific change that doesn’t fit their vision. Learn from the feedback, close the PR gracefully, and move on.

Read the contributing guide. Seriously. Every repo has quirks. Some want tests for every change. Some want a specific commit message format. Some want you to comment on the issue before opening a PR. Five minutes reading CONTRIBUTING.md saves hours of back-and-forth.

Diversify your repos. Don’t put all your effort into one project. Spread across multiple repos so you always have somewhere to make progress. Different repos teach you different things — different languages, different architectures, different review cultures.

The Numbers Keep Moving

By the time you read this, these numbers will be different. More PRs opened, more merged, more closed. That’s the nature of contributing at scale — it’s never “done.” There’s always another issue to pick up, another review to respond to, another CI failure to debug.

But that’s what makes it interesting. Every day is a different puzzle across a different codebase. The scale that once felt overwhelming now feels like momentum. And the systems I built to manage 50 PRs will scale to 500.

The code writes itself. The hard part is everything around it.