Add a note outling best practices around review and responding to it. Signed-off-by: Peter Krempa <pkre...@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
