git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH v2] MyFirstContribution: refrain from self-iterating too much

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 23, 2023, 04:18 UTC
Message-ID
<xmqqzga9opdu.fsf@gitster.g>
In-Reply-To
<xmqqcz76tv6d.fsf@gitster.g>

Finding mistakes in and improving your own patches is a good idea, but doing so too quickly is being inconsiderate to reviewers who have just seen the initial iteration and taking their time to review it. Encourage new developers to perform such a self review before they send out their patches, not after.

Helped-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/MyFirstContribution.txt | 30 +++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)
diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt
index ccfd0cb5f3..3e4f1c7764 100644
--- a/Documentation/MyFirstContribution.txt
+++ b/Documentation/MyFirstContribution.txt
@@ -1256,6 +1256,36 @@ index 88f126184c..38da593a60 100644
 [[now-what]]
 == My Patch Got Emailed - Now What?
 
+After you sent out your first patch, you may find mistakes in it, or
+a different and better way to achieve the goal of the patch.  But
+resist the temptation to send a new version immediately.
+
+ - If the mistakes you found are minor, send a reply to your patch as
+   if you were a reviewer and mention that you will fix them in an
+   updated version.
+
+ - On the other hand, if you think you want to change the course so
+   drastically that reviews on the initial patch would become
+   useless, send a reply to your patch to say so immediately to
+   avoid wasting others' time (e.g. "I am working on a better
+   approach, so please ignore this patch, and wait for the updated
+   version.")
+
+And give reviewers enough time to process your initial patch before
+sending an updated version.
+
+The above is a good practice if you sent your initial patch
+prematurely without polish.  But a better approach of course is to
+avoid sending your patch prematurely in the first place.
+
+Keep in mind that people in the development community do not have to
+see your patch immediately after you wrote it.  Instead of seeing
+the initial version right now, that you will follow up with several
+updated "oops, I like this version better than the previous one"
+versions over 2 days, reviewers would much appreciate if a single
+more polished version came 2 days late and that version, that
+contains fewer mistakes, were the only one they need to review.
+
 [[reviewing]]
 === Responding to Reviews
 
-- 
2.39.1-308-g56c8fb1e95
Previous: Junio C HamanoNext: Torsten Bögershausen
Message 5 of 20 in “MyFirstContribution: refrain from self-iterating too much”
  1. MyFirstContribution: refrain from self-iterating too muchJunio C Hamano, Jan 22, 2023
  2. Torsten BögershausenJan 22, 2023
  3. Junio C HamanoJan 22, 2023
  4. Junio C HamanoJan 22, 2023
  5. MyFirstContribution: refrain from self-iterating too muchJunio C Hamano, Jan 23, 2023
  6. Torsten BögershausenJan 23, 2023
  7. MyFirstContribution: refrain from self-iterating too muchJunio C Hamano, Jul 19, 2023
  8. Linus ArverJul 27, 2023
  9. Junio C HamanoJul 28, 2023
  10. MyFirstContribution: refrain from self-iterating too muchJunio C Hamano, Jul 28, 2023
  11. Jacob AbelJul 28, 2023
  12. Junio C HamanoJul 28, 2023
  13. Re* [PATCH v4] MyFirstContribution: refrain from self-iterating too muchJunio C Hamano, Jul 28, 2023
  14. Jacob AbelJul 29, 2023
  15. Junio C HamanoJul 31, 2023
  16. Linus ArverJul 28, 2023
  17. Junio C HamanoJul 28, 2023
  18. Torsten BögershausenJul 28, 2023
  19. Junio C HamanoJul 28, 2023
  20. Sean AllredJan 23, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.