On Mon, Jul 07, 2025 at 10:03:12PM -0700, Junio C Hamano wrote:
> Christian Couder <christian.couder@xxxxxxxxx> writes:
>
> > On Tue, Jul 8, 2025 at 12:58 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> >>
> >> Christian Couder <christian.couder@xxxxxxxxx> writes:
> >>
> >> > This v4 is just about fixing a few bugs in the tests using the SHA-256
> >> > object format compared to the v3. (I had issues with CI tests on v3,
> >> > so I sent it without waiting for the results.)
> >>
> >> We haven't heard much after a few comments were posted on this
> >> latest round, since Elijah's
> >> <20250619133630.727274-1-christian.couder@xxxxxxxxx>; I understand
> >> that it would be the author's turn to respond (the response does not
> >> necessarily have to be with an updated iteration). If so, let me
> >> mark the topic as Stalled in the draft of the latest issue of the
> >> "What's cooking" report.
> >
> > I will hopefully send a v5 later today.
>
> Thanks.
>
> By the way, I noticed that you often do not respond to reviews until
> the last minute, at the same time as when you send your next
> iteration, or even soon after doing so.
>
> That is quite different from how other contributors operate, i.e.
> respond and engage in discussions triggered by the reviews, and
> after people involved in discussion got an (even rough) idea of what
> the right next step would be, if not a total consensus, send the
> next iteration.
>
> I do not know which style is more efficient form of cooperation, but
> it somewhat makes my job harder, if I do not hear much _heartbeats_
> after I see review comments on the list. I do not mind waiting for
> seeing the next round for quite a while---after all, any substantial
> (re)work takes time. And responding to reviews may need thinking
> things through carefully, which may take some time, so I would not
> demand an immediate response, either. But it would be nearly
> impossible to feel the current status of such a topic---a few review
> comments are seen, the author goes silent for a while, we cannot
> tell if the author is working on a new iteration or where the author
> and reviewers agree and disagree.
>
> Also a review response that comes at the same time or immediately
> after a new iteration is already sent out makes it look like the
> author is refusing to continue discussion and reviewers are not
> welcome to make follow-up suggestions during such a discussion.
>
> Instead, the next iteration comes as a fait accompli, and makes it
> less useful to continue the review discussion on the previous round
> by responding to such a late response.
I agree with your points. Overall, a fast response cycle is key to good
collaboration from my point of view. I think it not only makes your life
as a maintainer easier, but it also makes the reviewer feel like they
are being heard and is the prerequisite for good discussion.
On our team's handbook page [1] we have the following couple of bullet
points regarding how to respond to reviews:
* Respond to feedback that you have received as fast as possible. A
fast exchange is a prerequisite for a fruitful discussion and
ensures that you keep momentum.
* On the other hand, it shouldn’t be necessary to respond to every
small typo correction in case you will send out the next version
soon anyway. If it will take a while before you send the next
version though it is nice to acknowledge nits, but mention that you
will hold off sending a new version of the series until you got more
feedback.
* Consider the viewpoint of the other person and be ready to disagree and
commit. Do not ignore feedback that you have received, as that will lead
to frustration and a decreased likelihood for that person to review your
future patch series.
Patrick
[1]: https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/git/#iteration
