@@ -72,12 +72,29 @@ guidance, and concrete tips for interacting with patches on the mailing list.
72
72
could fix it. This not only helps the author to understand and fix the issue,
73
73
it also deepens and improves your understanding of the topic.
74
74
75
- - Reviews do not need to exclusively point out problems. Feel free to "think out
75
+ - Reviews do not need to exclusively point out problems. Positive
76
+ reviews indicate that it is not only the original author of the
77
+ patches who care about the issue the patches address, and are
78
+ highly encouraged.
79
+
80
+ - Do not hesitate to give positive reviews on a series from your
81
+ work colleague. If your positive review is written well, it will
82
+ not make you look as if you two are representing corporate
83
+ interest on a series that is otherwise uninteresting to other
84
+ community members and shoving it down their throat.
85
+
86
+ - Write a positive review in such a way that others can understand
87
+ why you support the goal, the approach, and the implementation the
88
+ patches took. Make sure to demonstrate that you did thoroughly read
89
+ the series and understood problem area well enough to be able to
90
+ say that the patches are written well. Feel free to "think out
76
91
loud" in your review: describe how you read & understood a complex section of
77
92
a patch, ask a question about something that confused you, point out something
78
- you found exceptionally well-written, etc. In particular, uplifting feedback
79
- goes a long way towards encouraging contributors to participate more actively
80
- in the Git community.
93
+ you found exceptionally well-written, etc.
94
+
95
+ - In particular, uplifting feedback goes a long way towards
96
+ encouraging contributors to participate more actively in the Git
97
+ community.
81
98
82
99
==== Performing your review
83
100
- Provide your review comments per-patch in a plaintext "Reply-All" email to the
0 commit comments