architecture – How to defend reducing the strength of code review?

I don’t know how to argue for weaker code reviews, but I know to argue that code reviews aren’t being done properly.

Code reviews serve multiple purposes, skipping them simply because of time is silly. Don’t argue for that.

Code reviews are conversations, every comment should be responded to, otherwise you aren’t really having a conversation.

How one responds is an entirely separate issue. It’s not necessary and it absolutely should not be required, that the response is to change the code.

Just changing the code is wrong, changing it with an “Ok” is marginally acceptable. Agreeing with the comment is great. Agreeing while explaining that because of REASON is ok. Disagreeing because of REASON and saying you don’t want to make the change should be fine. Disagreeing with proof that the suggestion doesn’t work is great.

Who approves a pull request is an organizational process issue, there’s no developmental reason it has to be done by anyone in particular. Likewise there’s no developmental reason why it can’t be done by a specific person.

In short, I think you need to focus on the fact that a reviewer says-so is insufficient reason to make a change, it has to be a convincing argument. And then push, not for the right to skip the review, but that it be given a higher priority. Doing reviews should be considered part of the job, if someone isn’t giving their input, that should be considered the equivalent of refusing to write code.