Prevent non-organization users from approving pull requests

[driesvints]

In my personal experience in working with GitHub over all the past years I have never felt that pull request approvals from non-organization members were useful. It's in my opinion that these only create noise on a pull request and don't contribute anything useful to the discussion. In most situations, as far as I know, only organization members are the right candidates to approve pull requests.

Therefor I want to suggest to provide an option on repository level or even organization level to close off pull request approvals (but not the entire review process) to non-organization members.

The only people that should approve pull requests in most situations, in my experience, are:

• Organization members
• Outside collaborators which were added to the repository
• Non-organization users who explicitly requested a review from by an organization member or outside collaborator (which can't be done at the moment but that's a separate issue)

I do believe that people should be able to continue to use the review process itself and comment on a pull request since it's valuable to receive feedback from non-organization members. However, a single "approval" by a non-organization member is never useful in my opinion and just adds noise to the pull request discussion. Basically I believe non-organization members should only be able to use the "comment" option when reviewing pull requests and not "approve" or "request changes".

Happy to hear anyone's thoughts on this! 🙂

[evi-liu]

Hi @driesvints, we totally hear you. We currently have on our roadmap the ability to restrict drive-by reviews in settings. Stay tuned, and I'll keep this thread updated with details.

[driesvints]

Thanks @evi-liu!

[Danack]

It sounds like you're already inclined to do this, but just in case more justification is needed....as well as not providing much value, they have at least two negative effects:

• Can be used for spoofing approval from project members. Someone using a username really similar to the name of an existing project member can lead to things appearing to be approved when they shouldn't be.

• They can be used for brigading/putting emotional pressure on maintainers. Occassionally, there are pull requests which quite a few users of a project might wish to see merged, but the maintainers of a project don't want to use. The emoji spam on issues is annoying in general, but it's really inappropriate for pull requests.

[dotproto]

I like this suggestion, but as I recall non-org members can be members of a repository. As such, it may be more useful to limit review permissions to repo members that have triage, write, maintain, or admin permissions.

[driesvints]

Hey @dot proto, that's what I meant with outside collaborators :)

But those don't have separate permissions. They're just added to the repository as admins. I think the permissions you mention can only be applied to organization members in teams. Nvm this.

[michellemerrill]

Hi @driesvints, we totally hear you. We currently have on our roadmap the ability to restrict drive-by reviews in settings. Stay tuned, and I'll keep this thread updated with details.

cc: @dotproto @Danack ... all.

📣 Update: This product enhancement published yesterday on our public roadmap! You can now track the issue here.

[driesvints]

Amazing, thanks @michellemerrill! 🥳

[willsmythe]

To close the loop on this, here is the blog post announcing a new moderation setting that lets admins limit "approve" and "request changes" to only users with explicit "read" (or above) access: https://github.blog/2021-11-01-github-keeps-getting-better-for-open-source-maintainers/