PRs merged per developer: reading the table without building a scoreboard
Merge Frequency per Developer counts PRs merged per person, per week, benchmarked into Elite/High/Medium/Low tiers, with an 8-week sparkline so a slowdown shows up before the average quietly absorbs it. Click a row and you're in that person's PR history. Here's how to read the table — and the one thing not to do with it.
| Developer | PRs merged | Avg / wk | Tier | 8-wk trend |
|---|---|---|---|---|
| P. Chen | 41 | 6.3 | Elite | |
| R. Okafor | 34 | 5.2 | Elite | |
| T. Bergström | 22 | 3.4 | High | |
| M. Novak | 9 | 1.1 | Medium | |
| J. Alvarado | 4 | 0.6 | Low |
Synthetic table, one row per developer.
What it measures, and where the data comes from
- PRs merged — total pull/merge requests attributed to that person that merged inside the selected window, one row per person across every connected source. Pulled from GitHub, GitLab, and Azure DevOps pull/merge requests.
- Avg / wk — merges divided by the number of weeks in the selected window, not by how long that person has actually been active in it. Everyone gets the same divisor. That's a real caveat, not a footnote: someone who joined three weeks into an 8-week window still gets their merges spread across all eight, so their Avg/wk reads lower than their actual pace — check tenure before you take a recent joiner's tier at face value.
- Tier — Elite (5+/wk), High (3+/wk), Medium (1+/wk), Low (below) — benchmarked against typical throughput for a healthy team, not against your fastest teammate.
- 8-week trend — weekly merge counts as a sparkline, so a slowdown shows up while it's still a blip, not once the average has already dragged down with it.
Click any row to drill into that developer's individual PR history — useful before you draw a conclusion from a single number in a table.
How to read it
Scan the Tier column first, not the raw PR counts — a junior engineer at High is doing fine; a principal engineer at Medium might be spending their week unblocking everyone else instead of merging their own work. The tier tells you where someone sits relative to a healthy baseline; it doesn't tell you why.
The sparkline is there to catch direction before level. A row can sit at High all quarter while the sparkline quietly trends down — that's the earlier signal, and it's the one worth a conversation before the average tier actually drops.
What it tells you over time
Picture the on-call week, the vacation, the day after a big merge lands — every one of those dips a person's average for exactly one window, and none of them mean anything about how that person works. What you're actually watching for is simpler to name than to compute: has this person's tier been lower for a full sprint, not just one window, with nothing on the calendar to explain it?
Example situations
1. A couple of rows parked at Medium or Low
| Developer | PRs merged | Avg / wk | Tier |
|---|---|---|---|
| P. Chen | 39 | 6.0 | Elite |
| R. Okafor | 28 | 4.3 | High |
| M. Novak | 7 | 0.9 | Medium |
| J. Alvarado | 3 | 0.5 | Low |
Two rows well below the rest of the team.
What you're seeing: the team clusters at High/Elite except two rows sitting at Medium and Low, week after week, not just this window.
How to react: don't read this as an effort problem. Check what those two are actually assigned — a Low tier next to a ticket queue full of infra migrations or on-call weeks is explained, not concerning. A Low tier on ordinary feature work is worth a direct conversation.
2. One or two names carrying most of the PR volume
| Developer | PRs merged | Avg / wk | Tier |
|---|---|---|---|
| P. Chen | 61 | 9.4 | Elite |
| R. Okafor | 55 | 8.5 | Elite |
| T. Bergström | 8 | 1.2 | Medium |
| M. Novak | 6 | 0.9 | Medium |
| J. Alvarado | 4 | 0.6 | Low |
Total PRs concentrated in two rows.
What you're seeing: two rows alone account for well over half the team's merged PRs, quarter after quarter. On paper that looks like two Elite performers carrying a team of laggards. It's actually a bus-factor problem wearing a productivity costume.
How to react: find out what P. Chen and R. Okafor own that nobody else touches. If it's a core service, a deploy pipeline, or the only two people who understand a legacy module, this table is quietly telling you what happens the week either one takes real time off.
Frequently asked
- What does merge frequency per developer measure?
- Pull requests merged per person per week, benchmarked into Elite, High, Medium and Low tiers, with an eight-week sparkline so a slowdown surfaces before the average absorbs it. Rows drill into that person's PR history.
- Should I use this to rank engineers?
- No. It is an input to a conversation, not a ranking. PR counts vary with the kind of work someone is doing, and using this as a scoreboard reliably produces smaller, emptier PRs rather than better delivery.
- What is a legitimate use of this table?
- Spotting a change in someone's own pattern — a sustained drop in their sparkline is a good reason to ask how they are getting on, which is the question the table is for.
Related widgets
- Commits per Developer — the lower-level activity view; cross-check before reading too much into a PR count alone.
- Velocity Leaderboard — team-level throughput, for when you need the aggregate instead of the per-person breakdown.
- DORA Metrics — where merge cadence rolls up into deploy frequency and lead time.
- Back to the widget reference.
Last updated