My interpretation of your comment is that if someone applies their experience and expertise during a code review, and comes up with issues or suggestions that are not part of a written standard, then you will assume that your evaluation (maybe of the merits of the case, or perhaps just the importance) is more worthwhile/accurate than theirs.
Also, your preferred approach is to passive aggressively let the PR sit until external pressures build enough to force it through.
Do I have that right? If so, I personally find that to be a deeply problematic approach. Though I can imagine situations where it would be defensible and even optimal -- but those situations would involve working with idiots and/or control freaks. In which case my preferred approach would be to find a different place to work.
Well you got it right. I was surrounded by control freaks. Today I am the happiest man on earth because I don't have to put up with the idiocy of code reviews anymore.
Pair programming, live coding sessions and study sessions. When we start implementing something we define the definition of done and the acceptance criteria. When the code passes linting and meets the acceptance criteria it is accepted. If it doesn't then it's clear why not. There is no such thing as a commit needs improvement. It either passes or fails based on the above.
Also, your preferred approach is to passive aggressively let the PR sit until external pressures build enough to force it through.
Do I have that right? If so, I personally find that to be a deeply problematic approach. Though I can imagine situations where it would be defensible and even optimal -- but those situations would involve working with idiots and/or control freaks. In which case my preferred approach would be to find a different place to work.