{"thread":{"id":"59136","subject":"[PATCH] MyFirstContribution: refrain from self-iterating too much","startedAt":"2023-01-22T01:51:14Z","lastAt":"2023-07-31T15:25:26Z","messageCount":20,"participants":["Junio C Hamano","Torsten Bögershausen","Sean Allred","Linus Arver","Jacob Abel"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"470857","messageId":"xmqq3583uyk0.fsf@gitster.g","threadId":"59136","inReplyTo":null,"subject":"[PATCH] MyFirstContribution: refrain from self-iterating too much","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-01-22T01:51:11Z","receivedAt":"2023-01-22T01:51:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Finding mistakes in and improving your own patches is a good idea,\nbut doing so too quickly is being inconsiderate to reviewers who\nhave just seen the initial iteration and taking their time to review\nit. Encourage new developers to perform such a self review before\nthey send out their patches, not after.\n\nSigned-off-by: Junio C Hamano \n---\n Documentation/MyFirstContribution.txt | 20 ++++++++++++++++++++\n 1 file changed, 20 insertions(+)\n\ndiff --git c/Documentation/MyFirstContribution.txt w/Documentation/MyFirstContribution.txt\nindex 7c9a037cc2..81dcaedf0c 100644\n--- c/Documentation/MyFirstContribution.txt\n+++ w/Documentation/MyFirstContribution.txt\n@@ -1136,6 +1136,26 @@ index 88f126184c..38da593a60 100644\n [[now-what]]\n == My Patch Got Emailed - Now What?\n \n+You should wait for your patch to be reviewed by other people in the\n+development community. While you are waiting, you may want to\n+re-read what you wrote in the patch you already have sent, as if you\n+are a reviewer who is helping you to improve your patch. But resist\n+the temptation to update the patch and send a new one, until other\n+people had enough time to digest your original patch and give you\n+their reviews. They may be taking time to give you a carefully\n+written review responses and haven't finished it yet. Bombarding\n+them with new versions before they have a chance to react to the\n+first iteration is being rude to them.\n+\n+Of course, you still may spot mistakes and rooms for improvements\n+after you sent your initial patch. Learn from that experience to\n+make sure that you will do such a self-review _before_ sending your\n+patches next time. You do not have to send your patches immediately\n+once you finished writing them. It is not a race. Take your time\n+to self-review them, sleep on them, improve them before sending them\n+out, and do not allow you to send them before you are reasonably\n+sure that you won't find more mistakes in them yourself.\n+\n [[reviewing]]\n === Responding to Reviews\n \n"},{"id":"470871","messageId":"20230122071156.367jwwt3d5txvkl4@tb-raspi4","threadId":"59136","inReplyTo":"xmqq3583uyk0.fsf@gitster.g","subject":"Re: [PATCH] MyFirstContribution: refrain from self-iterating too much","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2023-01-22T07:11:57Z","receivedAt":"2023-01-22T07:12:07Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Sat, Jan 21, 2023 at 05:51:11PM -0800, Junio C Hamano wrote:\n> Finding mistakes in and improving your own patches is a good idea,\n> but doing so too quickly is being inconsiderate to reviewers who\n> have just seen the initial iteration and taking their time to review\n> it. Encourage new developers to perform such a self review before\n> they send out their patches, not after.\n>\n> Signed-off-by: Junio C Hamano \n> ---\n> Documentation/MyFirstContribution.txt | 20 ++++++++++++++++++++\n> 1 file changed, 20 insertions(+)\n>\n> diff --git c/Documentation/MyFirstContribution.txt w/Documentation/MyFirstContribution.txt\n> index 7c9a037cc2..81dcaedf0c 100644\n> --- c/Documentation/MyFirstContribution.txt\n> +++ w/Documentation/MyFirstContribution.txt\n> @@ -1136,6 +1136,26 @@ index 88f126184c..38da593a60 100644\n> [[now-what]]\n> == My Patch Got Emailed - Now What?\n>\n> +You should wait for your patch to be reviewed by other people in the\n> +development community. While you are waiting, you may want to\n> +re-read what you wrote in the patch you already have sent, as if you\n> +are a reviewer who is helping you to improve your patch. But resist\n> +the temptation to update the patch and send a new one, until other\n> +people had enough time to digest your original patch and give you\n> +their reviews. They may be taking time to give you a carefully\n> +written review responses and haven't finished it yet. Bombarding\n> +them with new versions before they have a chance to react to the\n> +first iteration is being rude to them.\n> +\n> +Of course, you still may spot mistakes and rooms for improvements\n> +after you sent your initial patch.\n\nI can't resist the question: After outlining what not to do and why,\ncould there be a hint what to do ?\nIt may be, that the author justs spots a simple typo, or there may\nbe more heavier changes to be done.\n\nShould the author just respond to her/his patch as a reviewer does ?\nLike:\nOps, there is a \"typax\", I should have written \"typo\".\nOr:\nRe-reading my own stuff, I think that things could have been done\nin a way like this....\nLets wait for more comments before I send out a new version.\n\n>+ Learn from that experience to\n> +make sure that you will do such a self-review _before_ sending your\n> +patches next time. You do not have to send your patches immediately\n> +once you finished writing them. It is not a race. Take your time\n> +to self-review them, sleep on them, improve them before sending them\n> +out, and do not allow you to send them before you are reasonably\n> +sure that you won't find more mistakes in them yourself.\n> +\n> [[reviewing]]\n> === Responding to Reviews\n>\n"},{"id":"470880","messageId":"xmqqcz76tv6d.fsf@gitster.g","threadId":"59136","inReplyTo":"20230122071156.367jwwt3d5txvkl4@tb-raspi4","subject":"Re: [PATCH] MyFirstContribution: refrain from self-iterating too much","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-01-22T16:01:46Z","receivedAt":"2023-01-22T16:01:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen writes:\n\n>> +Of course, you still may spot mistakes and rooms for improvements\n>> +after you sent your initial patch.\n>\n> I can't resist the question: After outlining what not to do and why,\n> could there be a hint what to do ?\n\nThere already is and it is the theme of the next paragraph.\n\nPeople on the list do not have to see your patch immediately after\nyou wrote it. Instead of seeing the initial version right now that\nis followed by a series of \"oops, I like this verison better than\nthe previous one\" rerolls over 2 days, reviewers would appreciate if\na single more polished version came 2 days late and that version was\nthe only one they need to review.\n\nWait, re-read what you wrote, fix the problems you find locally, all\nwithout sending it out until you find no more \"oops, that would not\nwork\" and simple typos. Sleep on it. \n\nOf course, people are not perfect so they may still find issues\nafter they sent their patches out.\n\n> It may be, that the author justs spots a simple typo, or there may\n> be more heavier changes to be done.\n>\n> Should the author just respond to her/his patch as a reviewer does ?\n> Like:\n> Ops, there is a \"typax\", I should have written \"typo\".\n\nFollow that with the same \"I will fix this typo when I reroll, but\nI'll wait for reviews from others\" as the other one, and it would be\nthe second best thing you could do (the best is to avoid having to\nsay that, of course).\n\n> Or:\n> Re-reading my own stuff, I think that things could have been done\n> in a way like this....\n> Lets wait for more comments before I send out a new version.\n\nAgain, very good.\n"},{"id":"470887","messageId":"xmqqsfg2qynx.fsf@gitster.g","threadId":"59136","inReplyTo":"xmqqcz76tv6d.fsf@gitster.g","subject":"Re: [PATCH] MyFirstContribution: refrain from self-iterating too much","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-01-22T17:14:42Z","receivedAt":"2023-01-22T17:14:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Torsten Bögershausen writes:\n>\n>> Or:\n>> Re-reading my own stuff, I think that things could have been done\n>> in a way like this....\n>> Lets wait for more comments before I send out a new version.\n>\n> Again, very good.\n\nThe latter one (different course) needs spearate treatment from the\nformer (typofix). Small corrections without changing course is\nbetter communicated with \"will fix when I reroll\" while a drastic\nchange should warn the readers not to waste their time on the\npremature initial version, i.e. \"I came up with a drastically\ndifferent and better idea; please ignore the one I just posted and\nwait for an updated one\".\n\nI'll sleep on what I rewrote to see if I or other people find better\nphrasing.\n\nThanks.\n\n\n"},{"id":"470894","messageId":"87cz76c8sb.fsf@gmail.com","threadId":"59136","inReplyTo":"xmqq3583uyk0.fsf@gitster.g","subject":"Re: [PATCH] MyFirstContribution: refrain from self-iterating too much","fromName":"Sean Allred","fromEmail":"allred.sean@gmail.com","sentAt":"2023-01-23T01:47:45Z","receivedAt":"2023-01-23T01:57:31Z","isPatch":true,"sender":{"key":"allred.sean@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2082195?v=4"},"body":"First review on this list; let me know if I've missed any decorum :-)\n\nJunio C Hamano writes:\n> +Of course, you still may spot mistakes and rooms for improvements\n> +after you sent your initial patch. Learn from that experience to\n> +make sure that you will do such a self-review _before_ sending your\n> +patches next time. You do not have to send your patches immediately\n> +once you finished writing them. It is not a race. Take your time\n> +to self-review them, sleep on them, improve them before sending them\n> +out, and do not allow you to send them before you are reasonably\n> +sure that you won't find more mistakes in them yourself.\n\nSomething of a nit:\n\n do not allow you to send them...\n\nshould be\n\n do not allow yourself to send them...\n\nYou're also using 'them' a *lot* which took me for a tumble my first\nread-through. I lost track of what 'them' actually was. Since this\ndocumentation is especially likely to be read by those who are already\nconfused by the process, it may be beneficial to be more explicit at\nsome points:\n\n ...\n\n patches next time. You do not have to send your patches immediately\n once you finished writing them. It is not a race. Take your time to\n review your own patches, sleep on them, and improve them. Do not\n allow yourself to send out your patches for review before you are\n reasonably sure you won't find more mistakes in them yourself.\n\n--\n\nThanks for all the work you do on this list; it's much appreciated.\n\n-Sean\n\n--\nSean Allred\n"},{"id":"470897","messageId":"xmqqzga9opdu.fsf@gitster.g","threadId":"59136","inReplyTo":"xmqqcz76tv6d.fsf@gitster.g","subject":"[PATCH v2] MyFirstContribution: refrain from self-iterating too much","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-01-23T04:18:05Z","receivedAt":"2023-01-23T04:18:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Finding mistakes in and improving your own patches is a good idea,\nbut doing so too quickly is being inconsiderate to reviewers who\nhave just seen the initial iteration and taking their time to review\nit. Encourage new developers to perform such a self review before\nthey send out their patches, not after.\n\nHelped-by: Torsten Bögershausen \nSigned-off-by: Junio C Hamano \n---\n Documentation/MyFirstContribution.txt | 30 +++++++++++++++++++++++++++\n 1 file changed, 30 insertions(+)\n\ndiff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\nindex ccfd0cb5f3..3e4f1c7764 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -1256,6 +1256,36 @@ index 88f126184c..38da593a60 100644\n [[now-what]]\n == My Patch Got Emailed - Now What?\n \n+After you sent out your first patch, you may find mistakes in it, or\n+a different and better way to achieve the goal of the patch. But\n+resist the temptation to send a new version immediately.\n+\n+ - If the mistakes you found are minor, send a reply to your patch as\n+ if you were a reviewer and mention that you will fix them in an\n+ updated version.\n+\n+ - On the other hand, if you think you want to change the course so\n+ drastically that reviews on the initial patch would become\n+ useless, send a reply to your patch to say so immediately to\n+ avoid wasting others' time (e.g. \"I am working on a better\n+ approach, so please ignore this patch, and wait for the updated\n+ version.\")\n+\n+And give reviewers enough time to process your initial patch before\n+sending an updated version.\n+\n+The above is a good practice if you sent your initial patch\n+prematurely without polish. But a better approach of course is to\n+avoid sending your patch prematurely in the first place.\n+\n+Keep in mind that people in the development community do not have to\n+see your patch immediately after you wrote it. Instead of seeing\n+the initial version right now, that you will follow up with several\n+updated \"oops, I like this version better than the previous one\"\n+versions over 2 days, reviewers would much appreciate if a single\n+more polished version came 2 days late and that version, that\n+contains fewer mistakes, were the only one they need to review.\n+\n [[reviewing]]\n === Responding to Reviews\n \n-- \n2.39.1-308-g56c8fb1e95\n\n"},{"id":"470942","messageId":"20230123175804.2bkcr7yawyz5fhkb@tb-raspi4","threadId":"59136","inReplyTo":"xmqqzga9opdu.fsf@gitster.g","subject":"Re: [PATCH v2] MyFirstContribution: refrain from self-iterating too much","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2023-01-23T17:58:04Z","receivedAt":"2023-01-23T18:03:21Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Sun, Jan 22, 2023 at 08:18:05PM -0800, Junio C Hamano wrote:\n\nThe whole thing is much more convenient to read, so to say.\nSome nit-picking inline.\n\n> Finding mistakes in and improving your own patches is a good idea,\n> but doing so too quickly is being inconsiderate to reviewers who\n> have just seen the initial iteration and taking their time to review\n> it. Encourage new developers to perform such a self review before\n> they send out their patches, not after.\n\nI think that this is what V1 was about. Review first, send then.\nIs there still so much focus on this ?\nOr is it more about \"what to do when it went wrong?\"\n\nHow about this, or similar ?\n\n...it. Encourage developers to wait with a new version too early.\nBut if they plan to send one later, they are welcome to comment\ntheir own work as they where reviers.\n\n\n>\n> Helped-by: Torsten Bögershausen \n> Signed-off-by: Junio C Hamano \n> ---\n> Documentation/MyFirstContribution.txt | 30 +++++++++++++++++++++++++++\n> 1 file changed, 30 insertions(+)\n>\n> diff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\n> index ccfd0cb5f3..3e4f1c7764 100644\n> --- a/Documentation/MyFirstContribution.txt\n> +++ b/Documentation/MyFirstContribution.txt\n> @@ -1256,6 +1256,36 @@ index 88f126184c..38da593a60 100644\n> [[now-what]]\n> == My Patch Got Emailed - Now What?\n>\n> +After you sent out your first patch, you may find mistakes in it, or\n> +a different and better way to achieve the goal of the patch. But\n> +resist the temptation to send a new version immediately.\n> +\n> + - If the mistakes you found are minor, send a reply to your patch as\n> + if you were a reviewer and mention that you will fix them in an\n> + updated version.\n> +\n> + - On the other hand, if you think you want to change the course so\n> + drastically that reviews on the initial patch would become\n> + useless, send a reply to your patch to say so immediately to\n> + avoid wasting others' time (e.g. \"I am working on a better\n> + approach, so please ignore this patch, and wait for the updated\n> + version.\")\n> +\n> +And give reviewers enough time to process your initial patch before\n> +sending an updated version.\n> +\n> +The above is a good practice if you sent your initial patch\n> +prematurely without polish. But a better approach of course is to\n> +avoid sending your patch prematurely in the first place.\n> +\n> +Keep in mind that people in the development community do not have to\n> +see your patch immediately after you wrote it. Instead of seeing\n> +the initial version right now, that you will follow up with several\n> +updated \"oops, I like this version better than the previous one\"\n> +versions over 2 days, reviewers would much appreciate if a single\n> +more polished version came 2 days late and that version, that\n> +contains fewer mistakes, were the only one they need to review.\n> +\n> [[reviewing]]\n> === Responding to Reviews\n>\n> --\n> 2.39.1-308-g56c8fb1e95\n>\n"},{"id":"479645","messageId":"xmqq8rbbbzp2.fsf_-_@gitster.g","threadId":"59136","inReplyTo":"20230123175804.2bkcr7yawyz5fhkb@tb-raspi4","subject":"[PATCH v3] MyFirstContribution: refrain from self-iterating too much","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-07-19T17:04:09Z","receivedAt":"2023-07-19T17:04:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Finding mistakes in and improving your own patches is a good idea,\nbut doing so too quickly is being inconsiderate to reviewers who\nhave just seen the initial iteration and taking their time to review\nit. Encourage new developers to perform such a self review before\nthey send out their patches, not after. After sending a patch that\nthey immediately found mistakes in, they are welcome to comment on\nthem, mentioning what and how they plan to improve them in an\nupdated version, before sending out their updates.\n\nHelped-by: Torsten Bögershausen \nSigned-off-by: Junio C Hamano \n---\n * Sorry for a slow update. Even though the topic is about not\n updating too quickly, this update was long overdue. Not a whole\n lot changed. Primary change is the later part of the proposed\n log message, which was helped by Torsten's comments, to which\n this message is a response to.\n\n Documentation/MyFirstContribution.txt | 31 +++++++++++++++++++++++++++\n 1 file changed, 31 insertions(+)\n\ndiff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\nindex ccfd0cb5f3..1ede3f8e37 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -1256,6 +1256,37 @@ index 88f126184c..38da593a60 100644\n [[now-what]]\n == My Patch Got Emailed - Now What?\n \n+After you sent out your first patch, you may find mistakes in it, or\n+a different and better way to achieve the goal of the patch. But\n+please resist the temptation to send a new version immediately.\n+\n+ - If the mistakes you found are minor, send a reply to your patch as\n+ if you were a reviewer and mention that you will fix them in an\n+ updated version.\n+\n+ - On the other hand, if you think you want to change the course so\n+ drastically that reviews on the initial patch would become\n+ useless, send a reply to your patch to say so immediately to\n+ avoid wasting others' time (e.g. \"I am working on a better\n+ approach, so please ignore this patch, and wait for the updated\n+ version.\")\n+\n+Then give reviewers enough time to process your initial patch before\n+sending an updated version (unless you retracted the initial patch,\n+that is).\n+\n+Now, the above is a good practice if you sent your initial patch\n+prematurely without polish. But a better approach of course is to\n+avoid sending your patch prematurely in the first place.\n+\n+Keep in mind that people in the development community do not have to\n+see your patch immediately after you wrote it. Instead of seeing\n+the initial version right now, that will be followed by several\n+updated \"oops, I like this version better than the previous one\"\n+versions over 2 days, reviewers would more appreciate if a single\n+polished version came 2 days late and that version with fewer\n+mistakes were the only one they need to review.\n+\n [[reviewing]]\n === Responding to Reviews\n \n-- \n2.41.0-376-gcba07a324d\n\n"},{"id":"479947","messageId":"owlycz0deykz.fsf@fine.c.googlers.com","threadId":"59136","inReplyTo":"xmqq8rbbbzp2.fsf_-_@gitster.g","subject":"Re: [PATCH v3] MyFirstContribution: refrain from self-iterating too much","fromName":"Linus Arver","fromEmail":"linusa@google.com","sentAt":"2023-07-27T23:14:52Z","receivedAt":"2023-07-27T23:14:59Z","isPatch":true,"sender":{"key":"linus@ucla.edu","avatar":null},"body":"I was in the process of writing a review but my comments were getting a\nbit long. So to save you the trouble of applying the suggested changes,\nI have a scissors patch version at the bottom with the changes applied\n(you may simply want to read that first).\n\nJunio C Hamano writes:\n\n> +After you sent out your first patch, you may find mistakes in it, or\n\ns/you sent/sending\n\nAlso, add \"perhaps realize\" after \"or\".\n\n> +a different and better way to achieve the goal of the patch. But\n> +please resist the temptation to send a new version immediately.\n> +\n> + - If the mistakes you found are minor, send a reply to your patch as\n> + if you were a reviewer and mention that you will fix them in an\n\ns/a/the\n\n> + updated version.\n> +\n> + - On the other hand, if you think you want to change the course so\n> + drastically that reviews on the initial patch would become\n> + useless, send a reply to your patch to say so immediately to\n> + avoid wasting others' time (e.g. \"I am working on a better\n> + approach, so please ignore this patch, and wait for the updated\n> + version.\")\n\nHow about this wording?\n\n - On the other hand, if you think you want to change the course so\n drastically that reviews on the initial patch would be a waste of\n time (for everyone involved), retract the patch immediately with\n a reply like \"I am working on a much better approach, so please\n ignore this patch and wait for the updated version.\"\n \n> +Then give reviewers enough time to process your initial patch before\n> +sending an updated version (unless you retracted the initial patch,\n> +that is).\n\nI think this paragraph should be moved inside the first one above. So it\ncould read something like this:\n\n Please give reviewers enough time to process your initial patch before\n sending an updated version. That is, resist the temptation to send a new\n version immediately (because it may be the case that others may have\n already started reviewing your initial version).\n\n While waiting for review comments, you may find mistakes in your initial\n patch, or perhaps realize a different and better way to achieve the goal\n of the patch. In this case you may communicate your findings to other\n reviewers as follows:\n\n> +Now, the above is a good practice if you sent your initial patch\n> +prematurely without polish. But a better approach of course is to\n> +avoid sending your patch prematurely in the first place.\n\nOK.\n\n> +Keep in mind that people in the development community do not have to\n> +see your patch immediately after you wrote it.\n\nHow about just\n\n Please be considerate of the time needed by reviewers to examine\n each new version of your patch.\n\n?\n\n> Instead of seeing\n\ns/Instead of/Rather than\n\n> +the initial version right now, that will be followed by several\n\ns/, that will be / (\n\n> +updated \"oops, I like this version better than the previous one\"\n\ns/updated//\n\n> +versions over 2 days, reviewers would more appreciate if a single\n\ns/versions over 2 days,/patches over 2 days),\n\ns/more appreciate/strongly prefer\n\n> +polished version came 2 days late and that version with fewer\n\ns/2 days late/instead,\n\n> +mistakes were the only one they need to review.\n\ns/need/would need/\n> +\n> [[reviewing]]\n> === Responding to Reviews\n> \n> -- \n> 2.41.0-376-gcba07a324d\n\nBelow is my scissor patch version.\n\n--8<---------------cut here---------------start------------->8---\nPlease give reviewers enough time to process your initial patch before\nsending an updated version. That is, resist the temptation to send a new\nversion immediately (because it may be the case that others may have\nalready started reviewing your initial version).\n\nWhile waiting for review comments, you may find mistakes in your initial\npatch, or perhaps realize a different and better way to achieve the goal\nof the patch. In this case you may communicate your findings to other\nreviewers as follows:\n\n - If the mistakes you found are minor, send a reply to your patch as if\n you were the reviewer and mention that you will fix them in an\n updated version.\n\n - On the other hand, if you think you want to change the course so\n drastically that reviews on the initial patch would be a waste of\n time (for everyone involved), retract the patch immediately with\n a reply like \"I am working on a much better approach, so please\n ignore this patch and wait for the updated version.\"\n\nNow, the above is a good practice if you sent your initial patch\nprematurely without polish. But a better approach of course is to avoid\nsending your patch prematurely in the first place.\n\nPlease be considerate of the time needed by reviewers to examine each\nnew version of your patch. Rather than seeing the initial version right\nnow (followed by several \"oops, I like this version better than the\nprevious one\" patches over 2 days), reviewers would strongly prefer if a\nsingle polished version came instead, and that version with fewer\nmistakes were the only one they would need to review.\n--8<---------------cut here---------------end--------------->8---\n \n"},{"id":"479948","messageId":"xmqq7cqkanm9.fsf@gitster.g","threadId":"59136","inReplyTo":"owlycz0deykz.fsf@fine.c.googlers.com","subject":"Re: [PATCH v3] MyFirstContribution: refrain from self-iterating too much","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-07-28T00:25:18Z","receivedAt":"2023-07-28T00:25:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Arver writes:\n\n> I was in the process of writing a review but my comments were getting a\n> bit long. So to save you the trouble of applying the suggested changes,\n> I have a scissors patch version at the bottom with the changes applied\n> (you may simply want to read that first).\n\nThanks. I very much like your version over the one you are\nresponding to, except for one minor point.\n\n>> +Keep in mind that people in the development community do not have to\n>> +see your patch immediately after you wrote it.\n>\n> How about just\n>\n> Please be considerate of the time needed by reviewers to examine\n> each new version of your patch.\n>\n> ?\n\nBoth give a useful piece of advice, but they are slightly different.\n\n> Please be considerate of the time needed by reviewers to examine each\n> new version of your patch. Rather than seeing the initial version right\n> now (followed by several \"oops, I like this version better than the\n> previous one\" patches over 2 days), reviewers would strongly prefer if a\n> single polished version came instead, and that version with fewer\n> mistakes were the only one they would need to review.\n\nWhat I wanted to convey with \"we do not need your initial patch\nimmediately\" was that it is perfectly fine if the cost of producing\nthe version \"reviewers would strongly prefer\" is that it takes 2\nmore days before they see such a more polished version. IOW, adding\nsomething like\n \n , even if it took 2 more days before they see the version.\n\nat the end of the above paragraph was what I wanted to say with\n\"hey, this is not a race. don't focus on sending immediately after\nyou wrote it. nobody is dying to see your patch immediately off the\npress\".\n\nThanks.\n"},{"id":"479949","messageId":"xmqqmszg987u.fsf_-_@gitster.g","threadId":"59136","inReplyTo":"xmqq7cqkanm9.fsf@gitster.g","subject":"[PATCH v4] MyFirstContribution: refrain from self-iterating too much","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-07-28T00:43:17Z","receivedAt":"2023-07-28T00:43:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Finding mistakes in and improving your own patches is a good idea,\nbut doing so too quickly is being inconsiderate to reviewers who\nhave just seen the initial iteration and taking their time to review\nit. Encourage new developers to perform such a self review before\nthey send out their patches, not after. After sending a patch that\nthey immediately found mistakes in, they are welcome to comment on\nthem, mentioning what and how they plan to improve them in an\nupdated version, before sending out their updates.\n\nHelped-by: Torsten Bögershausen \nHelped-by: Linus Arver \nSigned-off-by: Junio C Hamano \n---\n\nThe inter/range-diff with my v3 was totally useless, but here is to\nshow three minor edits I made to Linus's version I am responding to.\n\n * Simplify parenthesized \"because it may be the case that\".\n\n * As if you were \"a\" reviewer, as we do not designate \"the\n reviewer(s)\" to a patch. Anybody can (volunteer to) be a\n reviewer for a patch, and you can be, too.\n\n * Stress that a single polished patch that comes later (because it\n took time to polish) is vastly preferred than flurry of \"oops\n this is better\" updates.\n\n --- /var/tmp/b\t2023-07-27 17:38:56.928040307 -0700\n +++ /var/tmp/a\t2023-07-27 17:38:36.100067020 -0700\n @@ -1,7 +1,7 @@\n Please give reviewers enough time to process your initial patch before\n sending an updated version. That is, resist the temptation to send a new\n -version immediately (because it may be the case that others may have\n -already started reviewing your initial version).\n +version immediately, because others may have already started reviewing\n +your initial version.\n \n While waiting for review comments, you may find mistakes in your initial\n patch, or perhaps realize a different and better way to achieve the goal\n @@ -9,7 +9,7 @@\n reviewers as follows:\n \n - If the mistakes you found are minor, send a reply to your patch as if\n - you were the reviewer and mention that you will fix them in an\n + you were a reviewer and mention that you will fix them in an\n updated version.\n \n - On the other hand, if you think you want to change the course so\n @@ -26,5 +26,5 @@\n new version of your patch. Rather than seeing the initial version right\n now (followed by several \"oops, I like this version better than the\n previous one\" patches over 2 days), reviewers would strongly prefer if a\n -single polished version came instead, and that version with fewer\n -mistakes were the only one they would need to review.\n +single polished version came 2 days later instead, and that version with\n +fewer mistakes were the only one they would need to review.\n\nThanks.\n\n\n Documentation/MyFirstContribution.txt | 32 +++++++++++++++++++++++++++\n 1 file changed, 32 insertions(+)\n\ndiff --git a/Documentation/MyFirstContribution.txt b/Documentation/MyFirstContribution.txt\nindex ccfd0cb5f3..dd46f751b7 100644\n--- a/Documentation/MyFirstContribution.txt\n+++ b/Documentation/MyFirstContribution.txt\n@@ -1256,6 +1256,38 @@ index 88f126184c..38da593a60 100644\n [[now-what]]\n == My Patch Got Emailed - Now What?\n \n+Please give reviewers enough time to process your initial patch before\n+sending an updated version. That is, resist the temptation to send a new\n+version immediately, because others may have already started reviewing\n+your initial version.\n+\n+While waiting for review comments, you may find mistakes in your initial\n+patch, or perhaps realize a different and better way to achieve the goal\n+of the patch. In this case you may communicate your findings to other\n+reviewers as follows:\n+\n+ - If the mistakes you found are minor, send a reply to your patch as if\n+ you were a reviewer and mention that you will fix them in an\n+ updated version.\n+\n+ - On the other hand, if you think you want to change the course so\n+ drastically that reviews on the initial patch would be a waste of\n+ time (for everyone involved), retract the patch immediately with\n+ a reply like \"I am working on a much better approach, so please\n+ ignore this patch and wait for the updated version.\"\n+\n+Now, the above is a good practice if you sent your initial patch\n+prematurely without polish. But a better approach of course is to avoid\n+sending your patch prematurely in the first place.\n+\n+Please be considerate of the time needed by reviewers to examine each\n+new version of your patch. Rather than seeing the initial version right\n+now (followed by several \"oops, I like this version better than the\n+previous one\" patches over 2 days), reviewers would strongly prefer if a\n+single polished version came 2 days later instead, and that version with\n+fewer mistakes were the only one they would need to review.\n+\n+\n [[reviewing]]\n === Responding to Reviews\n \n-- \n2.41.0-470-gbfce02c22f\n\n"},{"id":"479951","messageId":"eaky7y2tprkzvhjdcg5vv2asekclywfcthzolpfu5o363423ca@b3p33bsbcqi5","threadId":"59136","inReplyTo":"xmqqmszg987u.fsf_-_@gitster.g","subject":"Re: [PATCH v4] MyFirstContribution: refrain from self-iterating too much","fromName":"Jacob Abel","fromEmail":"jacobabel@nullpo.dev","sentAt":"2023-07-28T02:07:25Z","receivedAt":"2023-07-28T02:07:39Z","isPatch":true,"sender":{"key":"jacobabel@nullpo.dev","avatar":"https://avatars.githubusercontent.com/u/9424043?v=4"},"body":"On 23/07/27 05:43PM, Junio C Hamano wrote:\n> Finding mistakes in and improving your own patches is a good idea,\n> but doing so too quickly is being inconsiderate to reviewers who\n> have just seen the initial iteration and taking their time to review\n> it. Encourage new developers to perform such a self review before\n> they send out their patches, not after. After sending a patch that\n> they immediately found mistakes in, they are welcome to comment on\n> them, mentioning what and how they plan to improve them in an\n> updated version, before sending out their updates.\n> \n> [...]\n>\n> +Please be considerate of the time needed by reviewers to examine each\n> +new version of your patch. Rather than seeing the initial version right\n> +now (followed by several \"oops, I like this version better than the\n> +previous one\" patches over 2 days), reviewers would strongly prefer if a\n> +single polished version came 2 days later instead, and that version with\n> +fewer mistakes were the only one they would need to review.\n> +\n> +\n> [...]\n\nSpeaking as a fairly green contributor to the project, it may be helpful\nto include some guidance on what is \"too long\" vs \"too short\" when\nwaiting to send out the next revision. \n\nLikewise it may be worthwhile to mention how the expected \"minimum time\nbetween revisions\" will generally shrink as you get to higher revision\ncounts and fewer changes between revisions.\n\n"},{"id":"479952","messageId":"owly8rb0g53d.fsf@fine.c.googlers.com","threadId":"59136","inReplyTo":"xmqqmszg987u.fsf_-_@gitster.g","subject":"Re: [PATCH v4] MyFirstContribution: refrain from self-iterating too much","fromName":"Linus Arver","fromEmail":"linusa@google.com","sentAt":"2023-07-28T02:08:54Z","receivedAt":"2023-07-28T02:09:29Z","isPatch":true,"sender":{"key":"linus@ucla.edu","avatar":null},"body":"Junio C Hamano writes:\n\n> ...\n>\n> The inter/range-diff with my v3 was totally useless, but here is to\n> show three minor edits I made to Linus's version I am responding to.\n>\n> * Simplify parenthesized \"because it may be the case that\".\n>\n> * As if you were \"a\" reviewer, as we do not designate \"the\n> reviewer(s)\" to a patch. Anybody can (volunteer to) be a\n> reviewer for a patch, and you can be, too.\n>\n> * Stress that a single polished patch that comes later (because it\n> took time to polish) is vastly preferred than flurry of \"oops\n> this is better\" updates.\n\nAll very reasonable and sensible. LGTM, thanks!\n"},{"id":"479956","messageId":"xmqq35188vu7.fsf@gitster.g","threadId":"59136","inReplyTo":"owly8rb0g53d.fsf@fine.c.googlers.com","subject":"Re: [PATCH v4] MyFirstContribution: refrain from self-iterating too much","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-07-28T05:10:40Z","receivedAt":"2023-07-28T05:11:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Arver writes:\n\n> Junio C Hamano writes:\n>\n>> ...\n>>\n>> The inter/range-diff with my v3 was totally useless, but here is to\n>> show three minor edits I made to Linus's version I am responding to.\n>>\n>> * Simplify parenthesized \"because it may be the case that\".\n>>\n>> * As if you were \"a\" reviewer, as we do not designate \"the\n>> reviewer(s)\" to a patch. Anybody can (volunteer to) be a\n>> reviewer for a patch, and you can be, too.\n>>\n>> * Stress that a single polished patch that comes later (because it\n>> took time to polish) is vastly preferred than flurry of \"oops\n>> this is better\" updates.\n>\n> All very reasonable and sensible. LGTM, thanks!\n\nThanks.\n"},{"id":"479957","messageId":"xmqq7cqk8vuk.fsf@gitster.g","threadId":"59136","inReplyTo":"eaky7y2tprkzvhjdcg5vv2asekclywfcthzolpfu5o363423ca@b3p33bsbcqi5","subject":"Re: [PATCH v4] MyFirstContribution: refrain from self-iterating too much","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-07-28T05:10:27Z","receivedAt":"2023-07-28T05:11:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Abel writes:\n\n> On 23/07/27 05:43PM, Junio C Hamano wrote:\n>> Finding mistakes in and improving your own patches is a good idea,\n>> but doing so too quickly is being inconsiderate to reviewers who\n>> have just seen the initial iteration and taking their time to review\n>> it. Encourage new developers to perform such a self review before\n>> they send out their patches, not after. After sending a patch that\n>> they immediately found mistakes in, they are welcome to comment on\n>> them, mentioning what and how they plan to improve them in an\n>> updated version, before sending out their updates.\n>> \n>> [...]\n>>\n>> +Please be considerate of the time needed by reviewers to examine each\n>> +new version of your patch. Rather than seeing the initial version right\n>> +now (followed by several \"oops, I like this version better than the\n>> +previous one\" patches over 2 days), reviewers would strongly prefer if a\n>> +single polished version came 2 days later instead, and that version with\n>> +fewer mistakes were the only one they would need to review.\n>> +\n>> +\n>> [...]\n>\n> Speaking as a fairly green contributor to the project, it may be helpful\n> to include some guidance on what is \"too long\" vs \"too short\" when\n> waiting to send out the next revision. \n\nWe generally do not want to be too prescriptive, as the right\ninterval depends on many factors like the complexity of the topic,\nhow busy the reviewers are otherwise, etc. And that is why I did\nnot go any more specific than \"several rounds within 2 days is way\ntoo frequent\".\n\nBut as a general common-sense guideline, I would encourage people to\nwait for at least one earth rotation, given that there are list\nparticipants across many timezones. I do not know offhand how to\nfit that well in the narrative being proposed, though.\n\n> Likewise it may be worthwhile to mention how the expected \"minimum time\n> between revisions\" will generally shrink as you get to higher revision\n> counts and fewer changes between revisions.\n\nI am not sure if I follow. As a topic gets iterated and getting\ncloser to completion, maximum time allowed between revisions to keep\nthe minds of those involved in the topic fresh may shrink, but I do\nnot think it would affect the minimum interval too much.\n\nThanks.\n"},{"id":"479970","messageId":"xmqqa5vg59ga.fsf_-_@gitster.g","threadId":"59136","inReplyTo":"xmqq7cqk8vuk.fsf@gitster.g","subject":"Re* [PATCH v4] MyFirstContribution: refrain from self-iterating too much","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-07-28T15:42:29Z","receivedAt":"2023-07-28T15:42:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jacob Abel writes:\n>\n>> Speaking as a fairly green contributor to the project, it may be helpful\n>> to include some guidance on what is \"too long\" vs \"too short\" when\n>> waiting to send out the next revision. \n>\n> We generally do not want to be too prescriptive, ...\n> But as a general common-sense guideline, I would encourage people to\n> wait for at least one earth rotation, given that there are list\n> participants across many timezones. I do not know offhand how to\n> fit that well in the narrative being proposed, though.\n\nOn top of v4, we could do something like this, I guess, but I\nrealize that this is talking about minimum waiting time to allow\nothers to even notice-see your patches, while the original is about\nthem needing time after noticing your patches to process them, and\nthe latter heavily depend on many factors (like how involved the\npatches are, how many people are likely to be interested in).\n\nSo, I doubt adding this is a good idea.\n\ndiff --git c/Documentation/MyFirstContribution.txt w/Documentation/MyFirstContribution.txt\nindex 93c9e459fc..440e9ede32 100644\n--- c/Documentation/MyFirstContribution.txt\n+++ w/Documentation/MyFirstContribution.txt\n@@ -1259,7 +1259,9 @@ index 88f126184c..38da593a60 100644\n Please give reviewers enough time to process your initial patch before\n sending an updated version. That is, resist the temptation to send a new\n version immediately, because others may have already started reviewing\n-your initial version.\n+your initial version. The development community members are across the\n+globe and it is a good idea to give them time to see your patches by\n+waiting for at least one rotation of the earth.\n \n While waiting for review comments, you may find mistakes in your initial\n patch, or perhaps realize a different and better way to achieve the goal\n"},{"id":"479975","messageId":"20230728212144.dpcbp6gfhfuiabia@tb-raspi4","threadId":"59136","inReplyTo":"xmqqmszg987u.fsf_-_@gitster.g","subject":"Re: [PATCH v4] MyFirstContribution: refrain from self-iterating too much","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2023-07-28T21:21:44Z","receivedAt":"2023-07-28T21:22:02Z","isPatch":true,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Thu, Jul 27, 2023 at 05:43:17PM -0700, Junio C Hamano wrote:\n> Finding mistakes in and improving your own patches is a good idea,\n> but doing so too quickly is being inconsiderate to reviewers who\n> have just seen the initial iteration and taking their time to review\n> it. Encourage new developers to perform such a self review before\n> they send out their patches, not after. After sending a patch that\n> they immediately found mistakes in, they are welcome to comment on\n> them, mentioning what and how they plan to improve them in an\n> updated version, before sending out their updates.\n\nThat's all good, no possible improvements from my side.\nHowever, a possible question below.\n\n[]\n\n> +Please give reviewers enough time to process your initial patch before\n> +sending an updated version. That is, resist the temptation to send a new\n> +version immediately, because others may have already started reviewing\n> +your initial version.\n> +\n> +While waiting for review comments, you may find mistakes in your initial\n> +patch, or perhaps realize a different and better way to achieve the goal\n> +of the patch. In this case you may communicate your findings to other\n> +reviewers as follows:\n> +\n> + - If the mistakes you found are minor, send a reply to your patch as if\n> + you were a reviewer and mention that you will fix them in an\n> + updated version.\n> +\n> + - On the other hand, if you think you want to change the course so\n> + drastically that reviews on the initial patch would be a waste of\n> + time (for everyone involved), retract the patch immediately with\n> + a reply like \"I am working on a much better approach, so please\n> + ignore this patch and wait for the updated version.\"\n> +\n(That's all good)\n\n\n> +Now, the above is a good practice if you sent your initial patch\n> +prematurely without polish. But a better approach of course is to avoid\n> +sending your patch prematurely in the first place.\n\nThat is of course a good suggestion.\nI wonder, how much a first time contributor knows about \"polishing\",\nin the Git sense ?\nFrom my experience, the polishing is or could be a learning process,\nwhich needs interaction with the reviewers.\nWould it make sense to remove the sentences above and ask people\nto mark their patch with RFC ?\n\nOr is this all too much bikeshedding, IOW I am happy with V4 as is.\n\n\n\n\n"},{"id":"479978","messageId":"xmqqsf973ami.fsf@gitster.g","threadId":"59136","inReplyTo":"20230728212144.dpcbp6gfhfuiabia@tb-raspi4","subject":"Re: [PATCH v4] MyFirstContribution: refrain from self-iterating too much","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-07-28T23:00:05Z","receivedAt":"2023-07-28T23:00:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Torsten Bögershausen writes:\n\n>> +While waiting for review comments, you may find mistakes in your initial\n>> +patch, or perhaps realize a different and better way to achieve the goal\n>> +of the patch. In this case you may communicate your findings to other\n>> +reviewers as follows:\n>> +\n>> + - If the mistakes you found are minor, send a reply to your patch as if\n>> + you were a reviewer and mention that you will fix them in an\n>> + updated version.\n>> +\n>> + - On the other hand, if you think you want to change the course so\n>> + drastically that reviews on the initial patch would be a waste of\n>> + time (for everyone involved), retract the patch immediately with\n>> + a reply like \"I am working on a much better approach, so please\n>> + ignore this patch and wait for the updated version.\"\n>> +\n> (That's all good)\n>\n>\n>> +Now, the above is a good practice if you sent your initial patch\n>> +prematurely without polish. But a better approach of course is to avoid\n>> +sending your patch prematurely in the first place.\n>\n> That is of course a good suggestion.\n> I wonder, how much a first time contributor knows about \"polishing\",\n> in the Git sense ?\n\nI do not know if \"without polish\" has any strong \"Git sense\" to\nbegin with. The actions the contributor would have done, referred\nto as \"the above\", are the result of re-reading their own patches\nand re-thinking their own approaches, which led them to discover\nfixes and alternative solutions, and I was hoping that \"without\npolish\" would be understood by anybody to mean \"a version that did\nnot go through such proofreading\" without knowing much about how we\ndevelop our patches.\n\nI am OK to just say \"sent your initial patch prematurely\" and\nwithout \"without polish\". I do think it would make the resulting\ntext encourage less strongly to proofread their own patches before\nsending them, but if you think \"polish\" may not be understood, I am\nfine with such a copyediting. Or using some alternative phrases is\nalso fine, if it improves our chances to be understood better.\n\n> From my experience, the polishing is or could be a learning process,\n> which needs interaction with the reviewers.\n\nYes, once they see what valuable insight reviewers offer, in their\nnext topic, they will learn to stop and think before sending the\nfresh-off-the-press version without sleeping on it a bit.\n\n> Would it make sense to remove the sentences above and ask people\n> to mark their patch with RFC ?\n\nI doubt it. Nobody will stay newbie forever. If they do not know\nwhat kind of flaws to look for and how to find them themselves in\ntheir work, that is perfectly OK and they can just send a regular\nPATCH. A reviewer hopefully will notice and point out that it is\nnot yet beyond RFC quality if that is the case, but this document\nshould not be suggesting that before seeing their work ;-)\n\n> Or is this all too much bikeshedding, IOW I am happy with V4 as is.\n\nThanks.\n"},{"id":"479979","messageId":"ivxtqzb46kp5uz5luuxkow6fjzwqrnvxu6f7mgu5a4mnatt6hc@djeykymbumn6","threadId":"59136","inReplyTo":"xmqqa5vg59ga.fsf_-_@gitster.g","subject":"Re: Re* [PATCH v4] MyFirstContribution: refrain from self-iterating too much","fromName":"Jacob Abel","fromEmail":"jacobabel@nullpo.dev","sentAt":"2023-07-29T02:12:05Z","receivedAt":"2023-07-29T02:12:16Z","isPatch":true,"sender":{"key":"jacobabel@nullpo.dev","avatar":"https://avatars.githubusercontent.com/u/9424043?v=4"},"body":"On 23/07/28 08:42AM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > Jacob Abel writes:\n> >\n> > [...]\n> \n> On top of v4, we could do something like this, I guess, but I\n> realize that this is talking about minimum waiting time to allow\n> others to even notice-see your patches, while the original is about\n> them needing time after noticing your patches to process them, and\n> the latter heavily depend on many factors (like how involved the\n> patches are, how many people are likely to be interested in).\n> \n> So, I doubt adding this is a good idea.\n>\n> [...]\n\nMaybe something along the lines of \"wait 24 hours after any discussion\nregarding the current revision has settled before publishing the next\nrevision\" would be a good guideline even if it's not included in this \npatch?\n\nBut I'm realising now that that is probably outside of the scope of\nthis specific change so apologies for what was likely me stepping into \nthe realm of bike shedding. \n\nI didn't mean to hold up the patch and I'm happy with v4.\n\n"},{"id":"479996","messageId":"xmqqr0oo14tc.fsf@gitster.g","threadId":"59136","inReplyTo":"ivxtqzb46kp5uz5luuxkow6fjzwqrnvxu6f7mgu5a4mnatt6hc@djeykymbumn6","subject":"Re: Re* [PATCH v4] MyFirstContribution: refrain from self-iterating too much","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-07-31T15:25:19Z","receivedAt":"2023-07-31T15:25:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Abel writes:\n\n> Maybe something along the lines of \"wait 24 hours after any discussion\n> regarding the current revision has settled before publishing the next\n> revision\" would be a good guideline even if it's not included in this \n> patch?\n\nPerhaps.\n\nUsually after an iteration or two of a topic, it will become clear\nwho are available and interested in the topic, and \"Wait and give\nthem enough time to respond to what you write\" would become the most\nappropriate guideline at that point.\n\nBut for new contributors and for more experienced ones alike, the\ninterest level from others is much harder to assess for the first\niteration, until everybody on the list has chance to notice and get\ninterested in the topic. So \"wait at least for 24 hours after\nposting the first iteration\" would be a good guideline for those who\ndo not know who on the list are the likely candidates to be\ninterested and know how quick their responses usually have\nhistorically been.\n\nA mistake I have often seen by new folks is to send their v2 soon\nafter they get a single minor response to their v1, without saying\nwhy they are sending v2 at the time (e.g. \"I am only fixing the typo\nthat was pointed out\"). It takes much shorter time to come up with\na response to point out a typo or two in the proposed log message\nthan giving a deeper analysis, which may only come after a few\niterations of such trivial changes.\n"}]}