Rulesets: exclude pull request contributors' approvals from merge requirements

[sulewicz-gq]

🏷️ Discussion Type

Product Feedback

Body

Feature request for Rulesets: exclude pull request contributors' approvals from merge requirements

Summary

Add a pull-request ruleset property that prevents approvals from pull request contributors from satisfying required-review rules.

For example:

{
  "type": "pull_request",
  "parameters": {
    "required_approving_review_count": 1,
    "exclude_contributor_approvals": true
  }
}

An alternative UI label could be:

Require approval from someone who did not contribute commits to the pull request

Problem

GitHub prevents a pull request author from approving their own pull request. However, the pull request author and the people contributing commits are not always the same identities.

This is common for pull requests opened by GitHub Apps and automation accounts. A human can add commits to a bot-authored pull request and then approve it. GitHub counts that approval because the bot is the pull request author, allowing the person who contributed the change to satisfy the review requirement.

This behavior affects pull requests created by development agents, dependency bots, migration tools, and other GitHub Apps.

The existing ruleset options do not express the required policy:

• Dismiss stale approvals on push invalidates otherwise valid independent approvals whenever reviewable changes are pushed.
• Require approval of the most recent reviewable push ties approval to the latest push and requires approval again after rebases and other branch updates.
• The existing pull request author restriction does not cover other users who authored or committed changes to a bot-owned pull request.

Proposed behavior

Add exclude_contributor_approvals to the pull-request rule parameters for repository, organization, and enterprise rulesets.

When enabled:

• GitHub continues to display reviews submitted by contributors.
• Approvals from contributors do not count toward required_approving_review_count.
• Contributor approvals do not satisfy CODEOWNERS or path-based required-team review requirements.
• An eligible approval from a non-contributor remains valid across pushes and rebases when stale-review dismissal is disabled.
• The approval does not need to target the current head SHA.
• If an approving reviewer subsequently becomes a contributor, their approval stops counting.
• GitHub explains in the merge box that the approval was excluded because the reviewer contributed commits to the pull request.

A contributor should include any GitHub user associated with the author or committer of a commit in the current pull request. GitHub may also include authenticated users who pushed the pull request commits where that identity is available.

Expected behavior

• A bot opens a pull request, Alice commits the change, and Alice approves. Alice's approval is visible but does not count.
• A bot opens a pull request, Alice commits the change, and Bob approves. Bob's approval counts.
• Bob approves, and Alice later rebases the branch. Bob's approval continues to count.
• Bob approves and later contributes a commit. Bob's approval stops counting.
• A human opens and contributes to their own pull request. Existing self-approval behavior remains unchanged.
• A contributor is also the required CODEOWNER. Their approval does not satisfy the CODEOWNER requirement.

Motivation

Organizations increasingly use automation to create pull requests while humans continue, amend, or replace the proposed changes. Review policy should follow who contributed the code, not only which account opened the pull request.

This property would close that gap without imposing the unrelated requirement that every push or rebase receive a new approval.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Blue101black]

With AI review bots now, it would be really great to exclude them from being a required approver. The workaround is to make a team that is required to review. But that is annoying because it notifies everyone.

GitHub copilot is ignored by a special case, would be nice if third-party agents get the same support.