[Feature Request] Partial CODEOWNER reviews

[tlconnor]

Select Topic Area

Product Feedback

Body

Pull requests will often trigger CODEOWNER reviews based on certain files within the repository. For larger pull requests the reviewers will then focus on their own areas of ownership and approve the PR based on the partial review.

I often see PR review comments that look something like:

Approved based on changes to [xyz] file

[Ownership area] looks good

[Owner team name] 👍

This can then result in approved pull requests that can be merged, even though only part of the changeset has been reviewed fully.

I would like to see GitHub have the ability for reviewers to give partial approvals for a subset of a pull request. This could be certain chunks, certain files, or simply clearing the CODEOWNER restriction without explicit approval.

A pull request would then only be mergable once all files / chunks have received approval.

[zoubingwu]

I like this idea, but I'm not sure this should only be limited to CODEOWNERS.

Currently, the "Viewed" checkbox on files within a Pull Request is a helpful but limited feature. It collapses the file for the current reviewer, acting as a personal progress tracker. I think we can extending this concept to create a "Partial Approve" state.

When a reviewer submits their review, they should have the option to formally approve the files they have marked as "Viewed". These files would then appear collapsed for all other reviewers on the PR, with a clear indication of who approved them. This would signal to the team that a specific portion of the PR has been vetted, allowing others to focus their attention on the remaining changes.

The Problem

The ideal of small, atomic Pull Requests is not always achievable in practice. A common scenario is a PR that introduces a breaking change in a core module. To keep the system buildable and functional, the developer must also update all dependent modules within the same PR.

This results in large, multi-faceted PRs that require input from different domain experts or code owners. For example:

• A change in a shared ApiService requires updates in BillingModule, UserProfileModule, and AdminDashboard.
• The BillingModule owner needs to review the billing-related files, the UserProfileModule owner needs to review the user profile files, and so on.

In the current system, there is no effective way for the BillingModule owner to formally sign off on just their part of the PR. Every other reviewer still sees all files as "pending review," leading to:

1. Reviewer Fatigue: Reviewers waste time re-examining code that has already been vetted by the appropriate expert.
2. Diffusion of Responsibility: It's unclear which parts of the PR have been thoroughly checked and by whom.
3. Slower Review Cycles: The overall process is slowed down as everyone feels obligated to understand the entirety of a massive change, even the parts outside their expertise.

Proposed Solution

I propose enhancing the review workflow with a "Partial Approve" capability:

1. Marking Files: A reviewer goes through the PR and checks the "Viewed" box for each file they are confident in approving, just as they do today.
2. Submitting a Partial Review: When submitting the review (via the "Review changes" button), a new option could be introduced, or the existing "Approve" action could be enhanced. For instance, an "Approve viewed files" option could be added.
3. Shared Collapsed State: Upon submission of this "partial review," the files that were marked "Viewed" are now collapsed by default for everyone else viewing the PR.
4. Clear Attribution: The collapsed file bar should clearly indicate who approved this section. For example: billing_service/invoice.go — Partially approved by @billing-expert.

This creates a trusted, shared state. Other reviewers can now confidently skip the sections approved by domain experts and focus their energy where it's most needed. They would, of course, retain the ability to expand and inspect the files if they wish.

Thank you for considering this proposal. I believe this feature would be a significant quality-of-life improvement for countless development teams on GitHub.