[PATCH v3] SubmittingPatches: address design critiques

[PATCH v3] SubmittingPatches: address design critiques

[Junio C Hamano]

Contributors sometimes fail to answer fundamental design or
viability comments from reviewers and submit subsequent rounds
without addressing them.  When design decisions are resolved on the
mailing list, the final justification should be recorded in the
commit messages.

Instruct authors to be particularly mindful of critiques regarding
high-level design or viability, to defend their choices on the list,
and to accompany new iterations with clearer explanations in the cover
letter, responses, and revised commit messages. Also instruct them to
explicitly document the resolution of these concerns in the commit
message body to keep the historical record complete.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * Updated a bit after reading comments by Kichael and Kristoffer

 Documentation/SubmittingPatches | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index f042bb5aaf..a9789e5303 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -51,6 +51,21 @@ area.
   respond to them with "Reply-All" on the mailing list, while taking
   them into account while preparing an updated set of patches.
 +
+Be particularly mindful of critiques regarding the high-level design
+or viability of your proposal (e.g., questioning if the feature is
+worth implementing, or if the chosen approach is appropriate).  Defend
+your design decisions on the list first, work with reviewers and other
+members to improve the design before revising the implementation, to
+avoid wasting effort on an implementation before its design is solid.
++
+Make sure that any new version explains and justifies those design
+decisions more clearly, in the cover letter and in the revised commit
+messages.  Aim to make the reviewers say "it is now clear why we may
+want to do this with the updated version".
++
+Topics with unresolved fundamental design critiques will not be
+considered ready for merging.
++
 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
@@ -323,6 +338,10 @@ The body should provide a meaningful commit message, which:
 
 . alternate solutions considered but discarded, if any.
 
+. records the resolution of design or viability concerns raised by the
+  community during the review, if any, ensuring the historical record
+  explains why the chosen approach was accepted over alternatives.
+
 [[present-tense]]
 The problem statement that describes the status quo is written in the
 present tense.  Write "The code does X when it is given input Y",
-- 
2.55.0-rc1-129-gff98d784de

Re: [PATCH v3] SubmittingPatches: address design critiques

[Michael Montalbo]

Junio C Hamano <gitster@pobox.com> writes:
> +Be particularly mindful of critiques regarding the high-level design
> +or viability of your proposal (e.g., questioning if the feature is
> +worth implementing, or if the chosen approach is appropriate).  Defend
> +your design decisions on the list first, work with reviewers and other
> +members to improve the design before revising the implementation, to
> +avoid wasting effort on an implementation before its design is solid.

Slight reflow suggestions:

  Defend your design decisions on the list first; work with reviewers and
  other members to improve the design before revising the implementation.
  This will avoid wasting effort on an implementation before its design is
  solid.

The rest looks good to me!

Re: [PATCH v3] SubmittingPatches: address design critiques

[Junio C Hamano]

Michael Montalbo <mmontalbo@gmail.com> writes:

> Slight reflow suggestions:
>
>   Defend your design decisions on the list first; work with reviewers and
>   other members to improve the design before revising the implementation.
>   This will avoid wasting effort on an implementation before its design is
>   solid.

Yeah, making the last part a separate sentence does make it much
easier to follow.  Will use.

Thanks.