git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jacob Abel <jacobabel@nullpo.dev>
Cc: git@vger.kernel.org, "Linus Arver" <linusa@google.com>,
	"Torsten Bögershausen" <tboegi@web.de>
Subject: Re: [PATCH v4] MyFirstContribution: refrain from self-iterating too much
Date: Thu, 27 Jul 2023 22:10:27 -0700	[thread overview]
Message-ID: <xmqq7cqk8vuk.fsf@gitster.g> (raw)
In-Reply-To: <eaky7y2tprkzvhjdcg5vv2asekclywfcthzolpfu5o363423ca@b3p33bsbcqi5> (Jacob Abel's message of "Fri, 28 Jul 2023 02:07:25 +0000")

Jacob Abel <jacobabel@nullpo.dev> writes:

> 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.

  reply	other threads:[~2023-07-28  5:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-22  1:51 [PATCH] MyFirstContribution: refrain from self-iterating too much Junio C Hamano
2023-01-22  7:11 ` Torsten Bögershausen
2023-01-22 16:01   ` Junio C Hamano
2023-01-22 17:14     ` Junio C Hamano
2023-01-23  4:18     ` [PATCH v2] " Junio C Hamano
2023-01-23 17:58       ` Torsten Bögershausen
2023-07-19 17:04         ` [PATCH v3] " Junio C Hamano
2023-07-27 23:14           ` Linus Arver
2023-07-28  0:25             ` Junio C Hamano
2023-07-28  0:43               ` [PATCH v4] " Junio C Hamano
2023-07-28  2:07                 ` Jacob Abel
2023-07-28  5:10                   ` Junio C Hamano [this message]
2023-07-28 15:42                     ` Re* " Junio C Hamano
2023-07-29  2:12                       ` Jacob Abel
2023-07-31 15:25                         ` Junio C Hamano
2023-07-28  2:08                 ` Linus Arver
2023-07-28  5:10                   ` Junio C Hamano
2023-07-28 21:21                 ` Torsten Bögershausen
2023-07-28 23:00                   ` Junio C Hamano
2023-01-23  1:47 ` [PATCH] " Sean Allred

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq7cqk8vuk.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jacobabel@nullpo.dev \
    --cc=linusa@google.com \
    --cc=tboegi@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).