Code review workflow where pull request author must merge

Several teams at my company practice a code review workflow I've never seen before. I am trying to understand the thinking behind it, with the idea that there's value in making the whole company consistent. (I contribute to multiple codebases and have been tripped up by the differences in the past.) Code author submits a pull request Reviewer examines the code If the reviewer approves, they leave a comment along the lines of "Looks good, feel free to merge" If the reviewer has concerns, they leave a comment like "Please fix minor issues X and Y, then merge" (For major changes, return to step 2) The code author makes changes if necessary, and then merges his or her own pull request I have the following concerns: In the case of approval at step 3, this workflow creates a seemingly-unnecessary roundtrip to the pull request author. The reviewer, who is already looking at the code, could just merge it immediately. In the case of changes being requested at step 3, the agency to merge the pull request now rests solely with the PR's author. No one besides the author will look at the changes prior to merging. What are some other advantages or disadvantages to this workflow? Is this workflow common on other engineering teams?

May 5, 2025 - 13:53

Several teams at my company practice a code review workflow I've never seen before. I am trying to understand the thinking behind it, with the idea that there's value in making the whole company consistent. (I contribute to multiple codebases and have been tripped up by the differences in the past.)

Code author submits a pull request
Reviewer examines the code
- If the reviewer approves, they leave a comment along the lines of "Looks good, feel free to merge"
- If the reviewer has concerns, they leave a comment like "Please fix minor issues X and Y, then merge" (For major changes, return to step 2)
The code author makes changes if necessary, and then merges his or her own pull request

I have the following concerns:

In the case of approval at step 3, this workflow creates a seemingly-unnecessary roundtrip to the pull request author. The reviewer, who is already looking at the code, could just merge it immediately.
In the case of changes being requested at step 3, the agency to merge the pull request now rests solely with the PR's author. No one besides the author will look at the changes prior to merging.

What are some other advantages or disadvantages to this workflow? Is this workflow common on other engineering teams?