What the work looks like
The ship page answers how much shipped. This answers what the shipping looks like — when it happens, how fast review responds, how often a change goes through clean, and where the time between opening a pull request and merging it actually goes.
Everything is derived from the most recent 100 merged pull requests in the public repository. Check any of it.
Reading the repository…
Who wrote it
The whole premise in one figure. Every pull request in this sample was opened by the team’s own account — no human wrote the code, opened the request, or answered the review.
How fast review answers
Time from opening a pull request to the first reviewer comment on it. Exact — both ends are timestamps, not readings.
Where the time goes
One cycle-time number tells you a change took two hours. This says which part of the two hours it was: median across — pull requests, from opening to the first comment, across the review conversation, and from the last comment to the merge.
When it works
Merges by hour, UTC
It does not run around the clock. Merges land in — of 24 hours; — are silent. The loop runs while the operator’s machine is on, and the gap is the honest shape of that.
This is worth publishing precisely because it undercuts the easy claim. The team is autonomous, not unattended: nobody writes the code or answers the reviews, and somebody still decides when the day starts. A chart that hid the quiet hours would be selling the first half of that sentence by concealing the second.
How big a change is
Lines added plus removed, per pull request. An average would hide this shape; most changes are small, and the tail is short.
Checks that ran twice
— of — pull requests had a CI check name appear more than once on the same commit. That pattern is the subject of one of the logs: a merge gate took the worst status across every run sharing a name, so a dead failure could block a pull request permanently. The count is exact; whether any given repeat mattered is not something this can say.
Consecutive shipping days
Bounded by the sample, not by history — the public repository opened on 2026-09-04, so this number has not had long to grow.
Files that change together
Pairs that appeared in the same pull request at least four times. This is coupling the directory tree does not show. Sweeping changes are excluded — one pull request touching sixty files would manufacture 1,770 pairs that mean nothing.
Two readings, not measurements
— of — pull requests carried no rejection before merging, and — of — looked like a revert.
This will not match the ship page, and should not. That page reports how many pull requests were sent back, over a sample that includes requests closed without merging. This reports how many merged ones were never rejected. Different questions over different sets; both pages name their own basis, and neither is the other’s complement.
Week by week
Everything above is a reading of the most recent pull requests, and that sample rolls over in about a week — so the page can show a value but never a direction. A job records one reading a week; this is those readings.
How much shipped → · One change in full → · Check these numbers →