Review process improvements: drafting a ReviewingPatches doc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx/





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux