I saw some contributors hesitate to give a positive review on
patches by their coworkers. When written well, a positive review
does not have to be a hollow "looks good" that rubber stamps an
useless approval on a topic that is not interesting to others.
Let's add a few paragraphs to encourage positive reviews, which is a
bit harder to give than a review to point out things to improve.
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
---
* Thanks for comments on the initial version. I spotted a few
typoes and grammos to fix, so here is a (hopefully final) update.
Documentation/ReviewingGuidelines.txt | 25 +++++++++++++++++++++----
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/Documentation/ReviewingGuidelines.txt b/Documentation/ReviewingGuidelines.txt
index 515d470d23..6534643cff 100644
--- a/Documentation/ReviewingGuidelines.txt
+++ b/Documentation/ReviewingGuidelines.txt
@@ -72,12 +72,29 @@ guidance, and concrete tips for interacting with patches on the mailing list.
could fix it. This not only helps the author to understand and fix the issue,
it also deepens and improves your understanding of the topic.
-- Reviews do not need to exclusively point out problems. Feel free to "think out
+- Reviews do not need to exclusively point out problems. Positive
+ reviews indicate that it is not only the original author of the
+ patches who care about the issue the patches address, and are
+ highly encouraged.
+
+- Do not hesitate to give positive reviews on a series from your
+ work colleague. If your positive review is written well, it will
+ not make you look as if you two are representing corporate
+ interest on a series that is otherwise uninteresting to other
+ community members and shoving it down their throat.
+
+- Write a positive review in such a way that others can understand
+ why you support the goal, the approach, and the implementation the
+ patches took. Make sure to demonstrate that you did thoroughly read
+ the series and understood problem area well enough to be able to
+ say that the patches are written well. Feel free to "think out
loud" in your review: describe how you read & understood a complex section of
a patch, ask a question about something that confused you, point out something
- you found exceptionally well-written, etc. In particular, uplifting feedback
- goes a long way towards encouraging contributors to participate more actively
- in the Git community.
+ you found exceptionally well-written, etc.
+
+- In particular, uplifting feedback goes a long way towards
+ encouraging contributors to participate more actively in the Git
+ community.
==== Performing your review
- Provide your review comments per-patch in a plaintext "Reply-All" email to the
Interdiff:
diff --git a/Documentation/ReviewingGuidelines.txt b/Documentation/ReviewingGuidelines.txt
index 31fd60aadf..6534643cff 100644
--- a/Documentation/ReviewingGuidelines.txt
+++ b/Documentation/ReviewingGuidelines.txt
@@ -81,13 +81,13 @@ guidance, and concrete tips for interacting with patches on the mailing list.
work colleague. If your positive review is written well, it will
not make you look as if you two are representing corporate
interest on a series that is otherwise uninteresting to other
- community members.
+ community members and shoving it down their throat.
- Write a positive review in such a way that others can understand
why you support the goal, the approach, and the implementation the
- patches taken. Make sure to demonstrate that you thoroughly read
+ patches took. Make sure to demonstrate that you did thoroughly read
the series and understood problem area well enough to be able to
- say if the patches are written well. Feel free to "think out
+ say that the patches are written well. Feel free to "think out
loud" in your review: describe how you read & understood a complex section of
a patch, ask a question about something that confused you, point out something
you found exceptionally well-written, etc.
--
2.46.0-rc2-56-g5eee0f42f3
