How do I spot bus-factor risk in review?

Look for review load concentrated on one or two names. If most reviews are given by a small minority, their absence will stall the whole review queue, which is a delivery risk rather than a fairness one.

Can this table show rubber-stamping?

Indirectly. A reviewer whose approvals almost exactly equal their reviews given is never requesting changes, which is worth a look alongside the Review Quality Index.

Code review participation: who's actually carrying your review load

Reviewer Participation is a plain two-column table — reviews given, and how many of those turned into an approval — one row per human reviewer across GitHub and Azure DevOps, with bots filtered out so a CI approval-bot doesn't dilute the picture. No tier, no trend, just who's showing up to review and how they're calling it.

deckgauge · Board · Reviewer Participation

Reviewer	Reviews given	Approvals
G. Andersen	71	52
R. Ibarra	64	61
N. Sato	18	14
F. Diallo	12	9
C. Reyes	8	7

Synthetic table, human reviewers only.

What it measures, and where the data comes from

Reviews given — how many PRs that person submitted a review on in the window, whether they approved, requested changes, or just left comments. Pulled from GitHub pull request reviews and Azure DevOps PR reviewer votes.
Approvals — of those reviews, how many landed as an approval. It's the gap between this and Reviews given that's informative, not either number alone.
Bots excluded — automated reviewers (merge bots, required-check bots, dependency-update approvers) are filtered out before this table is built, so the counts reflect actual humans reading actual diffs.

There's no benchmark tier and no trend line here on purpose — review load is too shaped by team size, role, and seniority for a universal "good" number, and this is meant to be read as one team's roster compared against itself, in the current window, not against an external bar.

Turnout, not judgmentThis table tracks who shows up to review and what button they clicked — nothing here says whether the review itself was any good. A reviewer with a huge count who skims and clicks approve isn't outperforming someone with a smaller count who actually catches bugs. Use this to check whether the workload is shared fairly, not to sort people into a ranking that decides who reviews better.

How to read it

Look at the spread across Reviews given first — in a healthy team of this size, review load should be reasonably close across everyone, not concentrated in two or three names while the rest of the roster sits in single digits. A wide spread is the table doing its job: telling you the load isn't shared.

Then look at each person's Approvals as a fraction of their Reviews given. A healthy reviewer has some gap there — some PRs get comments, some get a requested-changes round, most eventually get approved. A reviewer whose approvals sit almost exactly at their reviews-given count is worth a second look, not because they're doing something wrong, but because it's the pattern a rubber-stamp review leaves behind.

What it tells you over time

A healthy version of this table reshuffles its names every few weeks — whoever's deep in the gnarliest area right now picks up more reviews for a stretch, then hands the load back once that work ships. An unhealthy version freezes: the same one or two rows sit at the top release after release, and the approval ratio next to them never loosens up either. It's that second pattern — not any one busy week — that's worth pulling someone aside about, because a rubber-stamp habit doesn't show up in a single snapshot, it shows up in a ratio that refuses to move.

Example situations

1. A couple of reviewers carrying nearly all the load

deckgauge · Reviewer Participation

Reviewer	Reviews given	Approvals
G. Andersen	88	63
R. Ibarra	76	70
N. Sato	6	5
F. Diallo	4	4

Review load concentrated in two rows.

What you're seeing: G. Andersen and R. Ibarra together account for the vast majority of reviews on the team, while N. Sato and F. Diallo barely show up in this table at all. Every PR is funneling through two people.

How to react: this is a burnout risk for the two carrying the load and a bus-factor risk for the team — if either goes on leave, review turnaround for everyone else stalls. It's also worth asking whether the other reviewers aren't being asked, or aren't confident enough yet to weigh in.

Managerial playSet up a rotating reviewer-of-the-day so PRs don't default to the same two names out of habit, and make sure review assignment isn't quietly routing everything to whoever responds fastest. Explicitly credit review work in performance conversations — if it's invisible in perf, the two people doing the most of it are being penalized for carrying the team. Pair a quieter reviewer with a heavy one on a few PRs so they build the context and confidence to review solo.

2. Approvals nearly equal to reviews given

deckgauge · Reviewer Participation

Reviewer	Reviews given	Approvals
R. Ibarra	64	61
G. Andersen	71	52
N. Sato	18	10

One reviewer's approvals sitting almost 1:1 with reviews given.

What you're seeing: R. Ibarra's 61 approvals out of 64 reviews is a much tighter ratio than G. Andersen's 52 out of 71. That doesn't prove Ibarra is rubber-stamping — it's also what a reviewer who mostly reviews well-prepared PRs from senior engineers looks like — but it's the exact pattern worth a closer look either way.

How to react: before concluding anything, open a handful of Ibarra's actual reviews and read the comments, not just the verdict. A tight approval ratio with substantive inline comments on most PRs is a fast, good reviewer. The same ratio with one-line "LGTM" comments is a rubber stamp with a green checkmark on it.

Managerial playDon't confront this as an accusation — frame it as a coaching conversation about what good review looks like on this team, using a specific recent PR as the example. If the comments turn out substantive, say so and move on; the table did its job by pointing you at the right PR to check. If they don't, walk through one review together and show what a deeper pass would have caught.

Frequently asked

What does reviewer participation show?: A two-column table — reviews given, and how many became approvals — with one row per human reviewer across GitHub and Azure DevOps. Bots are filtered out so an automated approval does not dilute the picture.
How do I spot bus-factor risk in review?: Look for review load concentrated on one or two names. If most reviews are given by a small minority, their absence will stall the whole review queue, which is a delivery risk rather than a fairness one.
Can this table show rubber-stamping?: Indirectly. A reviewer whose approvals almost exactly equal their reviews given is never requesting changes, which is worth a look alongside the Review Quality Index.

Related widgets

Review Quality Index — the substance check for what this table only measures the shape of.
Review Mix — the bot-vs-human split of first reviews, plus median pickup time for each, GitHub only.
DORA Metrics — where review bottlenecks eventually show up as lead time.
Back to the widget reference.

Last updated 17 August 2026