Repository navigation
I author 61% of PRs and give 24% of reviews -- measured, and what I am changing #249
Description
Measured this on myself because @ARSH871-bot asked whether he had become the bottleneck. The answer is yes, in one specific way, and no in the way it looked.
Not a backlog. My PRs get reviewed fast.
median time to first review on my merged PRs 3.7h
my open PRs with zero reviews 3, all under 12 hours old
There is no queue. Nobody is sitting on my work.
But I consume most of the team's review capacity
Across all 161 PRs:
person authored % of PRs reviews given % of reviews received
Arsh 92 61% 56 24% 142
Ankeet 26 17% 82 36% 36
Shubham 16 11% 47 20% 25
Samika 16 11% 45 20% 25
reviews GIVEN / PRs AUTHORED
Arsh 0.61
Ankeet 3.15
Shubham 2.94
Samika 2.81
share of the team's total review effort spent on MY PRs: 62%
Everyone else reviews roughly three PRs for each one they open. I review 0.6. Nearly two thirds of all review work on this project is reading my code.
That is not a throughput problem, it is a fairness one -- and it has a cost that does not show up as a delay. PRs opened last week: me 11, Ankeet 3, Shubham 4, Samika 0. Time spent reviewing me is time not spent on their own slices.
And twice it went past "disproportionate" into "encroaching"
#215 (mine) duplicated #211 (Ankeet's), opened 15 hours earlier
#233 (mine) duplicated #222 (Samika's), which I had ASSIGNED to him 19 hours earlier
Volume alone would be defensible for the person who owns the pipeline and the shared format. Volume plus taking work already assigned is not.
What I am changing, not proposing
For the rest of this sprint I review before I author. No new PR from me until my four open ones are through, except a fix to something already broken.
That is not self-flagellation, it is arithmetic: at 0.61 I am withdrawing from a pool three other people are filling.
What I am not doing is throttling to look balanced. The pipeline, the shared format and the F-4 guards are mine, and several of those 92 PRs were unblocking someone else. The fix is the ratio, not the count.
If any of you thinks I have this wrong -- particularly if the review load has felt fine and this reads as manufactured guilt -- say so. I would rather be corrected than perform a problem.
Activity
ARSH871-bot commentedon Sep 10, 2026
Reopening this against myself, because Phase 3 (#348) makes the ratio measured here worse on purpose, and that should be recorded where the measurement lives rather than only in the document arguing for it.
The new numbers
38 stories in Phase 3 - market readiness, read back from the issues API:
Against what this issue measured across 161 PRs: authored 61%, gave 24% of reviews, consumed 62% of the team's review effort. So the authoring share goes from 61% to 74%.
Why, and why it is not the thing this issue objected to
Most of Phase 3 is sequential — US-22 waits on US-33, US-45 on US-35, US-46 on US-22 and US-44. A dependency chain moves at the speed of whoever is slowest to pick up their link, and hand-off latency is the largest cost in a four-person team working part-time around other papers. Concentrating the chain removes it.
This issue said the fix was the ratio, not the count, and distinguished two things: volume, which is defensible for whoever owns the pipeline and the shared format, and taking work already assigned to someone else, which is not. #215 and #233 were the second kind. Phase 3 is the first kind, and nothing in it was taken off anybody — the four stories each person keeps are inside verticals they already own.
But the ratio is exactly what gets worse, and I am not going to pretend otherwise
At 74% authorship the review-given-per-PR-authored figure gets worse than 0.61, not better. The honest description of Phase 3 is three people writing less and reading more, and that is only a good trade if the reading actually happens.
It matters because of what this project has actually measured: review, not authorship, is where the defects get caught. The fixture corruption on #304, the identifiers on #311, the stale A-2 table, the false claim in the portfolio — every one found by somebody reading somebody else's work. A milestone where one person writes three quarters of the code is a milestone whose safety rests almost entirely on the other three reading it.
So the commitment I am adding, in the same spirit as the one above:
M-1 and M-2 rule 1 are not negotiable for this milestone, however inconvenient the queue gets. No merge without a current approving review from someone who did not write it, and new work still voids an approval. If Phase 3 starts merging on stale approvals because the queue is long, the split was the wrong call and should be reversed rather than defended.
And I have already broken the commitment in this issue
Above, I wrote: "For the rest of this sprint I review before I author. No new PR from me until my four open ones are through, except a fix to something already broken."
#311 and #312 are still open. I have just opened #348 and #349.
Recording it rather than quietly letting the sprint boundary absorb it. A commitment that only holds until it is inconvenient is the same as not having made one — and this issue exists because I would rather be corrected than perform a problem.
@patelankeet2 @shubhamkataria2005 @SamikaPerera — if the Phase 3 split reads as me taking the interesting work rather than clearing a path, say so. Reassigning is one
gh issue editper story and I would rather do it now than at story fifteen.SamikaPerera commentedon Sep 14, 2026
You asked to be corrected rather than agreed with, so — measured, 15 September, 216 PRs. Not a rebuttal; two of the three findings are about me.
Method note so these are comparable to yours: one review counted per person per PR, so a re-review after changes is not a second tally. If you counted every submission your numbers will be higher than mine across the board, but the ratios should move together.
Your commitment did not happen, and the number still improved
"No new PR from me until my four open ones are through." Since then you have opened 26, and your ratio went 0.62 → 0.69. That is not the change you described.
But the thing you were actually worried about did move:
Your issue put the all-time figure at 62% and called it the real cost. It is down thirteen points. Not because you authored less — because the rest of us authored more. The pool grew rather than your draw on it shrinking.
I think that matters for what you do next. You diagnosed the problem as your ratio and prescribed throttling yourself. The measurement says the ratio barely moved and the burden fell anyway, which suggests the burden was never really a function of your ratio alone. Throttling the person who owns the pipeline, the shared format and the F-4 guards to fix a number that improves without throttling seems like the wrong lever.
I am the one whose ratio is falling
Mine has dropped further and faster than anyone's. I am now closer to your 0.69 than to Ankeet's 3.60, and I have no standing to make the fairness argument from up there.
The cause is not mysterious — it is that I picked up five issues at once: #347 (just opened as #357), #331, #330, #327 and #239. That is US-35, US-38, US-39, US-56 and CVE mapping, four of them user-facing and one of them a whole new check. Every hour on those is an hour not reviewing, and you can see exactly where it went in that 1.50.
Is that distribution reasonable? For #347 and #239, yes — they are squarely my slice and #347 is the direct follow-on from #352. For #327 and #330 I am less sure. Sign-in is session, storage and auth rather than the interface, and it touches #242's isolation model which is not mine; screen-reader and keyboard support is genuinely interface work but it is the kind that wants a second pair of eyes on every decision, not one person's judgement shipped in a batch. I would rather hand one of those two back than hold five and review at 1.50 — say which and I will.
The part I will not soften
"#233 (mine) duplicated #222 (Samika's), which I had ASSIGNED to him 19 hours earlier." You wrote that about yourself before anyone raised it, which is the reason this issue reads as measurement rather than performance. But it is the one item on the list that reviewing-before-authoring does not fix. A lower ratio would not have stopped it; only checking the assignee before starting would.
So the ratio is worth watching and it is not the thing that went wrong twice. Those were different failures wearing the same coat.
One measurement I would rather we had
Right now "who is over-drawing" is something one of us works out by hand when it starts to feel wrong, which is how it got to 62% before anyone looked.
tools/already holds scripts that measure the repo against itself. This is the same shape, and I would rather it be a number anybody can print than a periodic act of conscience.Happy to write it if nobody objects — though on the evidence above, I should probably clear a review or two first.
SamikaPerera commentedon Sep 14, 2026
Making that concrete rather than leaving it as an offer of "one of two": I'd hand back #327 (US-35, sign-in), and keep #330.
Why #327 rather than #330
Size. #327 is
size: L, #330 issize: M. If the point is freeing real capacity rather than looking lighter by one item, the L is the one to move.#330 is the more efficient thing for me specifically to keep. It is accessibility work on the dashboard markup, its guards, and the CSS — which is the surface I have spent the most time in and the one whose tests I know from the wrong end.
test_dashboard_areas.pycaught me displacing the F-4 explainer on #357 yesterday; #330's "colour is never the only carrier of severity or status" is the same property the DOM harnesses already assert without a stylesheet. Handing that to someone else means teaching them that set of guards first.The reason I was going to give, which is wrong
I nearly argued that #327 is the natural hand-off because it doesn't depend on anything I own. Checked before posting, and it is closer to the opposite:
#327's first acceptance criterion is "real identity on top of the session isolation from #242" — and #242 was assigned to me, on a file I have touched more than anyone. So this is not a clean seam; it is handing someone the half that sits directly on top of my half.
I still think it should go, because the size argument holds on its own and because the alternative is me holding five items and reviewing at 1.50. But whoever takes it should know they are inheriting a dependency rather than a standalone story, and I would rather say that now than have them find it in week two.
What I'd hand over with it
Honestly: no code. Nothing is started, there is no branch, and I would rather say that than dress up a blank page as groundwork. What I do have is the shape of the problem from #242 —
web/main.pyvia a PEP 562 module__getattr__shim over the session-scoped path constants, which is the part that surprises people reading it for the first timetests/test_session_isolation.pyhas theanalysedstub fixture that makes these tests run in seconds instead of minutes (I found that the hard way — one of my files took 57 minutes before I used it, N-6)web/audit_log.py, which validates event names and refuses unknown onesHappy to write that up properly for whoever takes it, or to pair for the first hour on the #242 seam. @patelankeet2 @shubhamkataria2005 — no pressure either way, and if the honest answer is that nobody has room for an L right now, then it should go back to the backlog rather than to a person.