Documentation: extend guidance for submitting patches

Before submitting patches on the mailing list, it is often a good idea
to check for previous related discussions or if similar work is already
in progress. This enables better coordination amongst contributors and
could avoid duplicating work.

Additionally, it is often recommended to give reviewers some time to
reply to a patch series before sending new versions. This helps collect
broader feedback and reduces unnecessary churn from rapid rerolls.

Document this guidance in "Documentation/SubmittingPatches" accordingly.

Signed-off-by: Justin Tobler <jltobler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index e270ccbe85b08720843e57751baabc164b2d58af..359f5fb74e699140e5be1ddb90bcaab4930223d7 100644 (file)
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -37,11 +37,24 @@ most likely to be knowledgeable enough to help you, but
 they have no obligation to help you (i.e. you ask them for help,
 you don't demand).  +git log -p {litdd} _$area_you_are_modifying_+ would
 help you find out who they are.
++
+It is also a good idea to check whether your topic has been discussed
+previously on the mailing list, or whether similar work is already in
+progress.  Prior discussions may contain useful context, design
+considerations, or earlier attempts at solving the same problem. Being
+aware of such discussions can help you avoid duplicating work and may
+allow you to coordinate with other contributors working in the same
+area.
 
 . You get comments and suggestions for improvements.  You may even get
   them in an "on top of your change" patch form.  You are expected to
   respond to them with "Reply-All" on the mailing list, while taking
   them into account while preparing an updated set of patches.
++
+It is often beneficial to allow some time for reviewers to provide
+feedback before sending a new version, rather than sending an updated
+series immediately after receiving a review. This helps collect broader
+input and avoids unnecessary churn from many rapid iterations.
 
 . Polish, refine, and re-send your patches to the list and to the people
   who spent their time to improve your patch.  Go back to step (2).