100 merged upstream

100 pull requests merged into 28 repositories I do not own.

// where they went

• hflow 22
• palinode 13
• domain-llm 12
• rago 8
• keep 7
• moto 7
• agno 3
• alltheplaces 2
• cognee 2
• jenkins.io 2
• keras 2
• trustgraph 2
• trustpoint 2
• UltraRAG 2
• agentic-security 1
• deepeval 1
• DeepTutor 1
• jc 1
• jupyter-mcp 1
• openai-agents 1
• opensciencelabs 1
• OWASP AI guide 1
• pandera 1
• pdm 1
• pylint 1
• PyMISP 1
• PyRIT 1
• sqlfluff 1

The list is more useful than the total. Three repositories account for nearly half of it, and most of the rest are single fixes in projects I passed through once and may never touch again.

// pick repos on ratio, not stars

What predicts whether I get anything merged is open issues divided by open PRs. A project with far more unanswered issues than pending patches has work nobody is doing. One where the two are close has more contributors than problems, and everything tractable is already taken.

Stars tell you nothing. A high merge rate for outside contributors tells you less than it looks like, because the account association GitHub shows on a merged PR reads the same for an employee as for a stranger. If a repo looks welcoming to outsiders, list the actual usernames before you believe it.

Read the CI config before you read the issues. Some projects cap outside contributors at one open PR and close the second automatically. Others gate workflow runs on maintainer approval, so your PR sits looking red when nothing has run at all. I spent an afternoon rebasing to chase green on a pipeline that had never started.

// the part that is not code

Most of the work in a first contribution to any project happens before the diff. Reading the contributing guide properly. Getting a test suite to run on a machine it was never tested on. Working out which of three overlapping conventions the maintainer actually cares about. Writing the PR description so a reviewer who has never seen you can tell in ten seconds whether to spend time on it.

That is also the part that decides whether it merges. A correct patch with a description nobody can parse sits open for a month.

// why bother

It is the only way I have found to get good at reading code I did not write. Every one of these started with an unfamiliar repository, someone else's conventions, and a test suite that would not run on the first try. That skill carries into everything else I build, and you cannot get it from your own projects, where you already know where everything is.

I keep a count because the count stops me from quietly doing nothing for a month. It is a forcing function, not a scoreboard.