👀 Reviewing: Allow different review types on your own PR

[Lamparter]

👀 Reviewing: Allow different review types on your own PR

Topic Area: Product Feedback

📝 I've tried to make this as concise as possible, please tell me if I could improve it!

---

Hi! I'm a developer who loves @github's PR feature of reviewing.
My request is that it it could be possible to add not only comments, but approving and/or request-change reviews on your own pull request.

📝 Struggling to understand what I mean? Here's a pic:

♿ Image caption: GitHub commit review box with the mouse cursor hovered over a radio button titled 'Request Changes' but GitHub is blocking it from being clicked, with a tooltip saying 'Pull request authors can't request changes on their own pull request.'

🤔 Why?

I believe this feature should be introduced because I use prs (especially for large changes) in my projects, which of course others collaborate with me on.
To elaborate, let me give an example:

• @mousemaid and @Lamparter are collaborating on a project called 'Fetch'.
• Fetch uses @python 2.7, as implemented by @mousemaid.
• @mousemaid has created a PR called 'Changes'
• @Lamparter decides to, in the 'Changes PR', bump the @python dependency in Fetch to @python 3.11, which causes the code to stop working.
• @mousemaid wants to revert the commit, but still wonders why @Lamparter would've done that.
• So, @mousemaid creates a review in the commit.
• But, because she created the 'Changes' PR she can't request changes!

- This example also applies to if the PR maker made the PR by accident, (it was intended for another to create the PR) or if the person who created it was not paying attention to the project at the time changes were made by others, then came back and wanted to reverse some of them.

[dmsnell]

There are times when I not only want review from others, but frequently have items I want to verify or tidy up before merging a PR. People get antsy and want to merge PRs as soon as they are reviewed, and there's no way to block one's own PR apart from returning it to a draft stage, which communicates a different set of expectations for the state of a branch.

I'd like to be able to block my own PR through a requests-changes review so that others will know not to merge it even if some people have given it their approval. For example, I may be waiting for review from a specific person, or waiting for some time to give people adequate time to review it if they want.

[robertmryan]

I’ll give another example of why we might want to be able to review my own PR: I was onboarding a new team member, showed him how he should create a PR for me to review, and now, having reviewed the PR, I can't approve it (nor send it back for review).

IMHO, the restriction should not be “who created the PR” but “who wrote the code”. And as project lead and owner of the repo, I should be able to approve what I want.

The branch protection rules have a concept of repo owner can do what they must, and you can optionally choose to protect a branch such that “Do not allow bypassing the above settings … The above settings will apply to administrators and custom roles with the ‘bypass branch protections’ permission.” IMHO, that's a useful pattern, probably one that should be used here.