Code review assignment
Code review assignment is the process of selecting which engineer will review a pull request. On most teams, this happens manually: someone opens a PR and either picks a reviewer, posts in Slack, or waits for a volunteer. The approach works until it doesn't.
What code review assignment means in practice
When a developer finishes work on a feature or fix, the changes need to be reviewed before merging. Someone has to decide who does that review. This decision happens many times per day on active teams.
The assignment can be explicit (tagging a specific person) or implicit (posting in a channel and waiting). Either way, the goal is the same: get qualified eyes on the code without creating bottlenecks.
On GitHub, assignment typically means adding a reviewer to a pull request. That person receives a notification and is expected to review the changes.
Common problems with reviewer assignment
Guessing who is available
You assign someone who looks free, but they're in the middle of deep work. The review sits for hours or days. Slack pings follow. This happens repeatedly.
The same people get assigned
Senior engineers and team leads often become default reviewers because they're visible and responsive. Over time, review load becomes uneven, and some team members rarely review code at all.
Slack requests create noise
Posting "anyone available to review?" in a channel generates notifications for everyone. People who are busy feel the pressure to respond. People who are available may not see it in time.
PRs stall without clear ownership
When no specific person is assigned, responsibility is diffused. The PR author waits. Potential reviewers assume someone else will handle it.
Manual assignment vs automated assignment
Manual assignment
- -PR author picks a reviewer based on their judgment
- -Works well when teams are small and co-located
- -Requires context on who knows what and who is busy
- -Scales poorly as team size increases
Automated assignment
- -A system selects the reviewer based on rules
- -Removes guesswork from the PR author
- -Can factor in data that humans can't easily track
- -Effectiveness depends on what signals the system uses
Most automated assignment tools use round-robin (rotating through a list) or code ownership (assigning based on who last touched the files). These approaches distribute load but ignore a key factor: whether the reviewer is actually available right now.
Availability as the missing signal
An engineer might be next in a round-robin queue, but they could be in meetings all day, handling an incident, or working against a deadline. Assigning them a review creates friction for everyone.
Availability is dynamic. It changes throughout the day and week. The only person who really knows their availability is the engineer themselves.
For assignment to work well, the system needs a way to know who is actually ready to take on a review. This information usually lives in people's heads or their calendar, neither of which is accessible to GitHub.
How CR Cab approaches code review assignment
CR Cab connects Slack to GitHub Actions. Engineers declare their availability using a simple Slack command. When a PR opens, a GitHub Action queries CR Cab for available reviewers and assigns one automatically.
The flow
- 1An engineer types
/cr_p1in Slack to indicate they're available for normal-priority reviews. - 2When heads-down, they type
/cr_offto pause assignments. - 3A PR opens in GitHub. The Action calls CR Cab's API.
- 4CR Cab returns available reviewers. The Action assigns one to the PR.
The PR author doesn't need to think about who to assign. The reviewer who gets assigned has explicitly indicated they're ready for reviews.
When this approach works well
- -Teams where engineers have variable schedules or work across time zones
- -Teams with enough reviewers that someone is usually available
- -Workflows where PRs need quick turnaround and delays are costly
- -Teams already using Slack and GitHub
- -Organizations that want to distribute review load more evenly
When this approach is not a fit
- -Very small teams (2-3 people) where manual assignment is trivial
- -Teams that require specific reviewers for compliance or regulatory reasons
- -Workflows where every PR must go to a designated code owner
- -Teams not using Slack (CR Cab requires Slack for availability signals)
- -Organizations with strict policies against third-party integrations
Simple setup overview
Setting up CR Cab takes about 10 minutes for most teams.
- 1.Install the CR Cab Slack app to your workspace.
- 2.Generate an API key from your account.
- 3.Add the API key as a secret in your GitHub repository.
- 4.Add a GitHub Action workflow that calls CR Cab on PR open.
- 5.Team members link their Slack and GitHub accounts.
Detailed instructions are available on the Get Started page.
Frequently asked questions
Does CR Cab handle code review assignment for all PR types?
CR Cab assigns reviewers for PRs where automated assignment makes sense. For PRs that require specific domain experts or designated code owners, you can still assign reviewers manually or configure rules in the Action workflow.
What happens if no one is available?
The API returns an empty list. Your GitHub Action can handle this however you prefer: skip assignment, assign a fallback reviewer, or notify a channel.
Can engineers opt out of being assigned?
Yes. Engineers control their own availability. Typing /cr_off in Slack removes them from the available pool until they opt back in.
What data does CR Cab store?
CR Cab stores availability status and the mapping between Slack and GitHub usernames. It does not store PR content, code, or messages. See the Privacy Policy for details.
How much does it cost?
Pricing starts at $29/month for small teams. All plans include a free trial with no credit card required. See the Pricing page.