Add a note outling best practices around review and responding to it.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
docs/submitting-patches.rst | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/docs/submitting-patches.rst b/docs/submitting-patches.rst
index 7bc22323ee..965e381cc1 100644
--- a/docs/submitting-patches.rst
+++ b/docs/submitting-patches.rst
@@ -89,3 +89,25 @@ Moreover, such patch needs to be prefixed correctly with
``--subject-prefix=PATCHv2`` appended to
``git send-email`` (substitute ``v2`` with the
correct version if needed though).
+
+Reviews
+-------
+
+Reviewing patches may take a lot of effort and review bandwidth is a limited
+resource for open source projects. Here are a few rules to follow to streamline
+the process:
+
+ - **don't** contact individual maintainers/developers directly with your
+ patches; reviewers are subscribed to the mailing list
+ - **do** be patient; reviewers may be busy
+ - **do** respond to reviewer's questions
+ - **don't** ignore a suggestion from a reviewer; if you disagree discuss it on
+ the list before sending a new version
+ - **do** remind us of your patches on the list if they haven't gotten any
+ attention for a prolonged period (> week) by replying to your patches with a
+ "ping"
+ - **do** test your pathches before sending
+
+You can also help out by reviewing other patches on the list if you feel
+comfortable. Don't hesitate to point out apparent problems in idividual patches,
+you are not obliged to review the whole series.
--
2.36.1