On Sun, Jan 22, 2023 at 08:18:05PM -0800, Junio C Hamano wrote: The whole thing is much more convenient to read, so to say. Some nit-picking inline. > 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. I think that this is what V1 was about. Review first, send then. Is there still so much focus on this ? Or is it more about "what to do when it went wrong?" How about this, or similar ? ...it. Encourage developers to wait with a new version too early. But if they plan to send one later, they are welcome to comment their own work as they where reviers. > > Helped-by: Torsten Bögershausen <tboegi@xxxxxx> > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> > --- > 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 >
