PR Reviewer Assignment Rotation

[mohan-shash]

Currently, PR review assignments often fall to the last person who modified the code or the designated component owner. This can lead to review bottlenecks, uneven distribution of work, and less exposure for other team members to different parts of the codebase. Implementing an automated rotation system, with a sprint-based refresh of the reviewer pool, will encourage broader team engagement in reviews, foster knowledge sharing, and improve overall code quality by leveraging diverse perspectives while adapting to changing team focuses per sprint.

---

As a bootc team member, I want PRs to be automatically assigned to a rotating pool of reviewers,
so that review responsibilities are more evenly distributed, everyone actively contributes to code reviews, and the appropriate SMEs are engaged when necessary, without relying solely on last touch or component ownership for initial assignments.

Acceptance Criteria:

• When a new Pull Request is opened in the bootc repository, it should not automatically default to the last committer or component owner for review.
• The system should identify a predefined pool of team members eligible for PR review.
• This pool of eligible reviewers should be updated/rotated at the beginning of each 3-week sprint.
• There should be a mechanism to allow for manual addition of Subject Matter Experts (SMEs) to a PR review, even after an automated assignment, without overriding the initial automated assignment.
• The process should be documented (may be in this issue) so team members understand how the rotation works and how to request specific reviews.
• The solution should integrate seamlessly with GitHub's PR workflow, potentially leveraging GitHub Actions or other available tools.

[cgwalters]

I think what could work well:

• Automation to sync from MAINTAINERS.md to a Github team https://github.com/orgs/bootc-dev/teams
• Use the default Github tooling to assign from a team

[cgwalters]

• kubevirt seems to use Prow (I don't think we want to go that route)
• We can use the builtin Github codeowners https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

[cgwalters]

This pool of eligible reviewers should be updated/rotated at the beginning of each 3-week sprint.

Digging into this we're thinking of taking a time-based number (seconds since the epoch, week number) and running that modulo the number of reviewers and taking that offset in the reviewer list.

OR

Just have a bot/human edit a column in MAINTAINERS.md

[gursewak1997]

What should we do when the author of a PR is also the assigned reviewer for that sprint? Should we automatically assign the next person in the rotation instead, or just fall back to GitHub's default reviewer assignment based on recent changes/component ownership?

[cgwalters]

What should we do when the author of a PR is also the assigned reviewer for that sprint? Should we automatically assign the next person in the rotation instead, or just fall back to GitHub's default reviewer assignment based on recent changes/component ownership?

Hmm yes we should not assign the PR submitter as a reviewer for sure

[mohan-shash]

I like the options you proposed, @gursewak1997. Could we try them in this order, though?

• Falling back to the default reviewer based on the recent change/component ownership (if that's the same as the author of the PR, then the next option)
• Assigning to the next person in the rotation list.

These are edge scenarios for sure, however, possible for us to hit.. so let's go with the expectation that there will be an assignment if/when needed.

[gursewak1997]

@mohan-shash: We initially planned to keep the default reviewer based on recent changes or component ownership, and add the person on rotation alongside them; this was discussed during one of the team syncs.

That said, I can definitely override that and assign only the person on rotation as the reviewer if preferred.

So Option 1 is already happening anyway, which makes assigning the next person in the rotation list a logical step.

[mohan-shash]

Ok.. assigning to the next person in rotation is good.

Question though:

We initially planned to keep the default reviewer based on recent changes or component ownership, and add the person on rotation alongside them; this was discussed during one of the team syncs.

In this case, do we get the benefits from rotating the PR reviewers?

[gursewak1997]

The main benefit of this approach is that the rotation still helps distribute awareness across the team, even if someone with more context is also assigned. Additionally, there are cases, like when adding a completely new file or feature where GitHub doesn’t auto-assign anyone. This setup ensures that someone is still assigned in those scenarios, maintaining review coverage.

That said, if we want to fully lean into the rotation, I can switch it to assign only the person in rotation as the reviewer; but I think having both assignees is a good starting point for this step.

[mohan-shash]

Thanks, that sounds good.