> when you make a comment in CR, also approve the commit. Trust the engineer on the other end to do what is necessary and responsible. If that become a problem

> when you make a comment in CR, also approve the commit. Trust the engineer on the other end to do what is necessary and responsible. If that become a problem, address it then. It seems like the minimum in professional respect. I agree wholeheartedly with this. One of my biggest pet peeves right now is having PRs delayed from merging because I can't get the required approvals over tiny non-vital changes. IMO a code review should only ever be rejected / not approved if it a) will bring down prod upon being committed, b) contains easily correctable but serious oversights (bad run time algos, potential NPEs, etc), or c) is built in a way that is not easily transferable / maintainable / goes against establish patterns by the team. Too many people use CR as a way to gatekeep and show off. I'm all for discussion, possible improvements, exchanging opinions, and learning - but not at the cost of leaving PRs in CR status for days on end.