Skip to content
Toprent.app Docs

6. [PROPOSAL] PR creation limits and review responsibility

Date: 2025-10-01

Status

Proposed

Context

When engineers have multiple open PRs, several problems arise:

  • Review bottleneck - If everyone is producing PRs but not reviewing, the review queue grows
  • Context thrashing - Jumping between writing new code and addressing review feedback is inefficient
  • Review debt - Team members avoid reviewing othersā€™ PRs because theyā€™re ā€œtoo busy codingā€
  • Blocked work - PRs sit waiting for review while engineers continue creating more
  • Quality issues - Rushed reviews happen when the queue gets too long

We need a discipline that balances code production with code review to keep work flowing.

Decision

Do not open more than 2-3 PRs without reviewing colleaguesā€™ PRs first.

The rule:

  • 2 open PRs - Youā€™re fine, keep coding
  • 3 open PRs - Time to review othersā€™ PRs before opening more
  • 4+ open PRs - You must review othersā€™ PRs; do not create new ones

When you hit the limit:

  1. Check the review queue - Look for PRs that need review
  2. Prioritize older PRs - Review PRs that have been waiting longest
  3. Review thoroughly - Donā€™t rush through reviews just to hit your quota
  4. Unblock others - Your reviews help move the teamā€™s work forward
  5. Return to your work - After reviewing, you can open new PRs

Exceptions:

  • Hotfixes - Critical production fixes can bypass this rule
  • Tiny PRs - Documentation-only or trivial changes (< 50 lines) may not count toward the limit
  • Blocked PRs - PRs waiting on external dependencies donā€™t count toward your limit

Why 2-3 PRs:

  • Allows working on multiple related changes
  • Provides flexibility for different-sized tasks
  • Ensures you have work to do while waiting for reviews
  • Forces periodic review participation

Consequences

Positive

  • Distributes review responsibility across the team
  • Prevents review queue from growing out of control
  • Improves review turnaround time
  • Encourages better PR sizing (people want to stay under the limit)
  • Builds team awareness of ongoing work
  • Creates natural breaks from ā€œheads-down codingā€ mode

Negative

  • Requires engineers to context-switch from coding to reviewing
  • May feel restrictive when youā€™re ā€œin the zoneā€
  • Requires discipline to follow the rule
  • Could slow down individual output in favor of team throughput

Neutral

  • Shifts focus from individual productivity to team throughput
  • Makes code review a first-class activity, not an afterthought
  • Creates a more sustainable review workload distribution
  • Encourages smaller, more focused PRs

Review Schedule

Review after 3 cycles to assess:

  • Is the review queue moving faster?
  • Are engineers reviewing more consistently?
  • Do we need to adjust the 2-3 PR limit?
  • Are there any unintended consequences?