Skip to content

rfc: dedicated review time and stacked PRs - #18

Merged
hannahhoward merged 2 commits into
mainfrom
rfc/review-time-and-stacked-prs
Aug 4, 2026
Merged

hannahhoward merged 2 commits into
mainfrom
rfc/review-time-and-stacked-prs

Conversation

@hannahhoward

@hannahhoward hannahhoward commented Aug 1, 2026 •

Copy link
Copy Markdown
Contributor

📖 Preview

Summary

Two commitments to fix our review bottleneck: an hour a day of calendar-held review time with a one-business-day first response, and stacked PRs for anything bigger than an hour's review — recommending GitHub's native stacked pull requests (with our Claude Code workflows taught to produce stacks), spr as fallback, Graphite in reserve.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Comment thread rfcs/2026-07-review-time-and-stacked-prs.md Outdated

## Proposal 1: dedicated review time

Each of us holds one hour a day on the calendar for review, checks the review queue before starting new build work, and gives a first response to any review request within one business day. Google's measured cost is about 3 hours a week, so an hour a day is deliberately above steady state: we have a review backlog to drain and agents multiplying our output. Revisit the number in a month.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with everything proposed here.

I suggest these additions to consider:

  1. Configure CODEOWNERS in each repository, so that every new PR automatically requests review from at least one person.
  2. Monitor "time to first response to a review request" on a per-user and team-wide basis. Every week, an automation should post a message to our eng Slack channel with a list of p50 & p90 for each team member.
  3. Implement basic alerting. For example: at noon in my local time, if there are any outstanding review requests from yesterday or before, send me a Slack DM with the list of review requests needing my attention.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Miro, simple slack reminder would be great.

Comment on lines +34 to +36
A PR should be reviewable in under an hour, which the evidence puts at roughly 400 changed lines, though the content is just as important -- critical auth logic takes longer than code-gen'd serialization for example. Therefore, bigger work must ship as a stack of dependent PRs, each one a reviewable step.

The norm binds our agents too. Each active repo's AGENTS.md gets an instruction that work expected to exceed the guide ships as a stack, and Claude Code gets the stack tooling below.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth adding some automation here as well? E.g. a GHA workflow that posts a warning comment to the PR discussion if the diff is larger than 400 lines.

@pyropy pyropy left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great initiative, I agree with everything in this RFC.


## Decisions needed

- **The hour.** I propose one hour a day. Google's measured average is about three hours a week, so this is deliberately generous while the backlog drains.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree as a baseline, I spend significantly more than this daily already though.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but you are one of the good ones

## Decisions needed

- **The hour.** I propose one hour a day. Google's measured average is about three hours a week, so this is deliberately generous while the backlog drains.
- **Pilot now vs. wait.** The GitHub preview is days old and will have sharp edges; spr covers the gaps. I propose pilot now.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pilot now 👍


- **The hour.** I propose one hour a day. Google's measured average is about three hours a week, so this is deliberately generous while the backlog drains.
- **Pilot now vs. wait.** The GitHub preview is days old and will have sharp edges; spr covers the gaps. I propose pilot now.
- **Size guardrails.** Social norm only, or a soft CI warning above ~400 changed lines? I lean social to start.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Social norm 👍

@parkan
parkan self-requested a review August 4, 2026 14:11
Co-authored-by: Miroslav Bajtoš <oss@bajtos.net>
@hannahhoward
hannahhoward merged commit ce9142c into main Aug 4, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants