+1 - It is easy to forget that it is possible to approve with comments. Not all review feedback should block a merge.
In my project we used to be allowed to approve with nits but recently they changed it that the code needs a re-review for almost any edits. The system has some criteria for which it will allow minor edits but it's strict enough that I've rarely seen it pass an edit. I assume there must have been some incident that triggered this.
Basically, an unaddressed nit doesn’t block merging. But any code changes will require fresh reviews.
If the change is very minor, it’s very quick for someone who has already approved to check the last commit diff and reapprove.
That said, if you can read the commits individually then final review for something where minor changes were added should be utterly trivial.
- Modify it and accept that this will trigger re-review
- Merge as-is... maybe they don't even agree with the nit
- Merge as-is and followup with a new MR under the same JIRA. This sometimes makes sense if it gets them into an important preprod environment, but they are really still working on the issue.
- Merge as-is and follow up with a JIRA on the backlog. Maybe they realized that the "nit" is really a bigger issue and should be addressed separately.
Regardless, there's value in not blocking the merge for non-functional issues.
Another useful thing, in my opinion, is to use your "fresh eyes" to make suggestions on what could use to be clarified in code or documentation. "This wasn't immediately obvious to me, could you add a comment on why it works this way?". The author is often too close to the code to see that it isn't obvious, because it is to them, because they've already spent hours thinking about it. But this should almost always what be optional suggestions. (But, rarely, code is so unclear that it really shouldn't go in without being clarified or documented.)
But in general I do think it's important to consistently be thinking to oneself "my goal is to be useful to my team and organization. are my comments achieving that? would it be more useful to approve or to not approve this right now?". The temptation to be a fastidious editor can be strong - if most of us didn't have this impulse we'd probably be doing different jobs... - but I find this "usefulness" framing to help me a lot in resisting it.
And very strong disagree on not requiring reviews. It is much better to tirelessly foster a low-friction review culture.