[PATCH v4] SubmittingPatches: address design critiques

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

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>
---
 * Hopefully this will be the last iteration.

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

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index f042bb5aaf..28b4f2f795 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -51,6 +51,22 @@ 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 and 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.
++
+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 +339,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",

Interdiff against v2:
  diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
  index a9789e5303..28b4f2f795 100644
  --- a/Documentation/SubmittingPatches
  +++ b/Documentation/SubmittingPatches
  @@ -54,9 +54,10 @@ area.
   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.
  +your design decisions on the list first and 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.
   +
   Make sure that any new version explains and justifies those design
   decisions more clearly, in the cover letter and in the revised commit
-- 
2.55.0-rc1-134-gb7e3543e07