Review process improvements: drafting a ReviewingPatches doc

Hi all,

In continuation of Emily’s "Review process improvements"[1], I am drafting a ReviewingPatches doc to help standardize the review process here on the git mailing list and to provide a rubric/checklist for new reviewers. In order to do so, I am looking to compile examples and input from everyone by asking the list a set of questions biweekly. Please contextualize your answer in terms of whether this was a maintainer, individual, or drive-by review.

Maintainer: in the context of the overall project, is this series a
good idea? Does it interact well with other features? Is it
maintainable in the long term?

Individual: in the context of the individual's own experience, is this
series a good idea? Is the implementation readable, correct, and
efficient?

Drive-by / nitpicks: does not answer whether the series is a good idea. Makes suggestions for missing pieces, bugs, and/or code style.

Here are the first set of questions I had in mind:

What is the best review(s) that you have ever received? What was especially constructive about this review and do you feel like it could be improved upon or is missing something? Conversely, what is the best review(s) that you have ever given? Feel free to leave examples for each of the review types.

[1] https://lore.kernel.org/git/YbvBvch8JcHED+A9@google.com/