Merge branch 'jt/doc-submitting-patches-study-before-sending'

Doc update for our contributors.

* jt/doc-submitting-patches-study-before-sending:
  Documentation: extend guidance for submitting patches

1 files changed, 13 insertions, 0 deletions

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index e270ccbe85..359f5fb74e 100644
--- 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).