Chronology

Every hour a pull request is open, somebody is holding it: a reviewer who has not looked yet, an author who owes a reply, or nobody, because it is approved and waiting to merge. Chronology, the second tab of Reports, adds up those hours across the workspace. It shows which wait is the bottleneck, whether each wait is inside the time you allow for it, and what the quick pull requests do differently from the slow ones. It names no person.

#What it measures

• Pull requests a person wrote, merged in the window you pick. Pull requests opened by automation, such as dependency bumps, are not measured here. Bots Monitoring covers them.
• Working hours. The charts count only the working hours set for the workspace, for example Monday to Friday, 09:00–17:30 in your time zone. Nights, weekends and days off do not count. Set them under Working hours and budgets in Settings → Reports and sprint.
• Three waits: With reviewer (waiting for a person to look, or to look again), With author (waiting for the author to answer a review) and Waiting to merge (approved and not merged yet).

#Choose the view and the window

1. Open Reports and choose Chronology.
2. Choose a view. In People, only people’s reviews and comments move a pull request on; work only a bot reviewed counts as merged without a review. In People + bots, a review or comment by Limn or by an AI review bot such as CodeRabbit also counts. Compare the two to see what your review bots change. The choice is saved for the workspace.
3. Choose a Window. The first option is the workspace’s reporting window; 30 days, 60 days and 90 days are longer views.

In both views, CI, quality gates and housekeeping bots never count, and a push counts whoever made it. Lines under the heading say which working hours apply, how many pull requests were measured and what was set aside.

#Where the working hours went

The aim is equal thirds. A marker shows where the window’s working hours sit between the three waits, with a ringed centre: inside the filled ring reads as balanced; past the dashed ring, one wait dominates. One very slow pull request can move the marker a long way, so the bar beside it gives the split as percentages.

The target leaves out pull requests approved on their first review, with no changes asked for. They never wait for their author, so they would pull every team away from the centre. A green number counts them, with a line showing that count week by week.

#Each wait against its time budget

Four waits are measured against a budget you set: First look (opened to the first human review or comment), Reply to review (review to the author’s answer), Approved to merged and Opened to merged. Each bar ends where three in four pull requests had finished that wait; a dot marks half, and a thin line runs on to nine in ten. The dashed line is the budget. The verdicts are Within budget, Acceptable, Past limit and, with too few pull requests, Too few to judge.

Above the budgets, Review target gives the share of merged pull requests whose first review came within the good mark of the first-look budget. Pending uses the same target: a review that has waited longer says “Over the review target”.

#The detail below

• Every pull request: one dot per merged pull request, by the day it merged and the working hours it was open. Colour shows which wait took most of its time; bigger dots changed more lines. Select a dot to open the pull request. A table lists the same pull requests for keyboard and screen-reader users.
• What the quick ones do differently: the quickest quarter against the slowest quarter, by size and by the day they opened. Clear difference? says Yes, Slight or No.
• Approved, waiting to merge: pull requests that waited more than a working day after approval, longest first, with any pull requests on the same ticket in other repositories that merged while they waited.
• Who gives the first review: for each repository, how many people give first reviews and how much the busiest one does. A high share is a cover risk for when that person is away. Nobody is named.
• Asking for a review: whether pull requests asked a named person, a team or nobody first, and how long each took to get a first look.
• By repository, in clock hours: a repository is called out only when one wait holds a large share of its time and its pull requests are slow. The rest are under Nothing stands out. Clock hours here, because the rule was set on them.
• Merged without a human review: repositories where pull requests a person wrote merged with no review, comment or approval from a person. This is a branch protection setting, not a habit.

Pointers

While AI is on, Write pointers asks AI for patterns, examples worth copying and things to try, from the pull requests on the page. Each pointer links the pull requests it is based on; one that cites none is dropped. Pointers name no one and contain no figures: every figure on this page is measured. Nothing is written until you press the button.

#Over time

Over time repeats the split and the budgets week by week for the last 26 weeks, by the week each pull request merged. Weeks with too few pull requests are drawn faint and left out of every comparison.

• Markers show when something first happened: a repository joined, a bot or a person was seen for the first time, or a setting changed. A dashed marker is a shift the numbers show on their own.
• Before and after: select a marker above the first chart to compare the weeks before it with the weeks after.
• Working hours saved against a baseline (the first eight usable weeks). Set an Hourly cost $ to see the hours in dollars. The cost is kept on your computer, for this workspace only.

#Why it helps

“Reviews are slow” and “authors are slow” need different fixes. Chronology tells you which one you have, whether it is getting better, and which repositories cause it, without ranking people. For the headline flow figures, see Read the Overview.