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

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

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 28, 2023, 05:10 UTC
Message-ID
<xmqq7cqk8vuk.fsf@gitster.g>
In-Reply-To
<eaky7y2tprkzvhjdcg5vv2asekclywfcthzolpfu5o363423ca@b3p33bsbcqi5>
Jacob Abel <jacobabel@nullpo.dev> writes:
Show 25 quoted lines
> On 23/07/27 05:43PM, Junio C Hamano wrote:
>> 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.  After sending a patch that
>> they immediately found mistakes in, they are welcome to comment on
>> them, mentioning what and how they plan to improve them in an
>> updated version, before sending out their updates.
>> 
>> [...]
>>
>> +Please be considerate of the time needed by reviewers to examine each
>> +new version of your patch. Rather than seeing the initial version right
>> +now (followed by several "oops, I like this version better than the
>> +previous one" patches over 2 days), reviewers would strongly prefer if a
>> +single polished version came 2 days later instead, and that version with
>> +fewer mistakes were the only one they would need to review.
>> +
>> +
>> [...]
>
> Speaking as a fairly green contributor to the project, it may be helpful
> to include some guidance on what is "too long" vs "too short" when
> waiting to send out the next revision. 

We generally do not want to be too prescriptive, as the right interval depends on many factors like the complexity of the topic, how busy the reviewers are otherwise, etc. And that is why I did not go any more specific than "several rounds within 2 days is way too frequent".

But as a general common-sense guideline, I would encourage people to wait for at least one earth rotation, given that there are list participants across many timezones. I do not know offhand how to fit that well in the narrative being proposed, though.

> Likewise it may be worthwhile to mention how the expected "minimum time
> between revisions" will generally shrink as you get to higher revision
> counts and fewer changes between revisions.

I am not sure if I follow. As a topic gets iterated and getting closer to completion, maximum time allowed between revisions to keep the minds of those involved in the topic fresh may shrink, but I do not think it would affect the minimum interval too much.

Thanks.
Previous: Jacob AbelNext: Junio C Hamano
Message 12 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.