Indeed, naming, comments and communication styles are three aspects often overlooked during reviews. They are very important though and shouldn't be neglected.

Excellent post about code reviews. I particularly like the introduction about the motivations, it's often forgotten.

We see this kind of comments in some reviews, this would benefit from being more widespread.

I'm not necessarily convinced this is as much a silver bullet as it is presented here. Still there are benefits to such a structured approach for reviews in community projects.

This trend around critiquing code reviews on the argument of "trust" should be challenged indeed. This is just the wrong way to approach it.

Since I've seen this argument floating around more than once, it's nice to have a properly done rebuttal of it. This is nicely done, listing the own bias of the author, still in the end that shows the logical flaw of the argument.

Interesting article. I especially like how it makes the difference between being kind and nice. That honesty is required if you want to be really kind to others. It nicely shows examples on how to apply this (for instance, but not only, in the context of code reviews).

Lots of good advices about processes and organizations. It's nicely points out that friction is not necessarily wrong... if you get something out of it.
Also neat reminder in there that code review are here to complete work which is already socialized somehow. If you can't find reviewers it's a sign of an organizational problem when the work started.

This explains fairly well the reason why I spend so much time doing git rebases or push for more readable history in branches submitted for reviews. It helps a lot with the reviews and with finding root causes of issues later on.

Interesting way to see where to spend time in reviews.

Not very profound but definitely useful tips on how to handle reviews.

Obviously I strongly agree with this. Participating in code reviews of free software components is a great way to improve. This applies to being a reviewer, submitting code and skimming other reviews.

Not 100% convinced by all the points, but definitely a good conversation to have around the pull/merge request model. Might need a minimum threshold to be crossed in term of team maturity though.

Bumped into this. It's indeed nice, full of good advises for handling code reviews.

Plenty of good advices for code reviews. Fairly comprehensive since it covers both ends of the review.