Re: [PATCH] Documentation: extend guidance for submitting patches

[Junio C Hamano <gitster@pobox.com>]

Justin Tobler <jltobler@gmail.com> writes:

> 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>
> ---
>  Documentation/SubmittingPatches | 13 +++++++++++++
>  1 file changed, 13 insertions(+)

What's written in these two new paragraphs are all agreeable, but is
the first addition in the right place with correct mark-up?

This whole section is a sequence of bullet points that shows "a
typical life cycle of a patch series".  The first bullet point
starts with "You come up with an itch." and the second one is "You
send the patches", whose end part is what we see in the pre-context
of the patch, ending with "help you find out who they are."

If the new paragraph is meant as yet another paragraph to elaborate
on that second bullet point, wouldn't we need that "a line with only
a single '+' on it" before it, instead of a blank line, and the last
line of the first new paragraph should not be such a "single '+'"
line but a plain vanilla blank line?

> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index e270ccbe85..5acd692ad7 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -38,10 +38,23 @@ 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).
>
> base-commit: 628a66ccf68d141d57d06e100c3514a54b31d6b7