| Message ID | xmqqa5vg59ga.fsf_-_@gitster.g (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Re* [PATCH v4] MyFirstContribution: refrain from self-iterating too much | expand |
On 23/07/28 08:42AM, Junio C Hamano wrote: > Junio C Hamano <gitster@pobox.com> writes: > > > Jacob Abel <jacobabel@nullpo.dev> writes: > > > > [...] > > On top of v4, we could do something like this, I guess, but I > realize that this is talking about minimum waiting time to allow > others to even notice-see your patches, while the original is about > them needing time after noticing your patches to process them, and > the latter heavily depend on many factors (like how involved the > patches are, how many people are likely to be interested in). > > So, I doubt adding this is a good idea. > > [...] Maybe something along the lines of "wait 24 hours after any discussion regarding the current revision has settled before publishing the next revision" would be a good guideline even if it's not included in this patch? But I'm realising now that that is probably outside of the scope of this specific change so apologies for what was likely me stepping into the realm of bike shedding. I didn't mean to hold up the patch and I'm happy with v4.
Jacob Abel <jacobabel@nullpo.dev> writes: > Maybe something along the lines of "wait 24 hours after any discussion > regarding the current revision has settled before publishing the next > revision" would be a good guideline even if it's not included in this > patch? Perhaps. Usually after an iteration or two of a topic, it will become clear who are available and interested in the topic, and "Wait and give them enough time to respond to what you write" would become the most appropriate guideline at that point. But for new contributors and for more experienced ones alike, the interest level from others is much harder to assess for the first iteration, until everybody on the list has chance to notice and get interested in the topic. So "wait at least for 24 hours after posting the first iteration" would be a good guideline for those who do not know who on the list are the likely candidates to be interested and know how quick their responses usually have historically been. A mistake I have often seen by new folks is to send their v2 soon after they get a single minor response to their v1, without saying why they are sending v2 at the time (e.g. "I am only fixing the typo that was pointed out"). It takes much shorter time to come up with a response to point out a typo or two in the proposed log message than giving a deeper analysis, which may only come after a few iterations of such trivial changes.
diff --git c/Documentation/MyFirstContribution.txt w/Documentation/MyFirstContribution.txt index 93c9e459fc..440e9ede32 100644 --- c/Documentation/MyFirstContribution.txt +++ w/Documentation/MyFirstContribution.txt @@ -1259,7 +1259,9 @@ index 88f126184c..38da593a60 100644 Please give reviewers enough time to process your initial patch before sending an updated version. That is, resist the temptation to send a new version immediately, because others may have already started reviewing -your initial version. +your initial version. The development community members are across the +globe and it is a good idea to give them time to see your patches by +waiting for at least one rotation of the earth. While waiting for review comments, you may find mistakes in your initial patch, or perhaps realize a different and better way to achieve the goal