Re: [PATCH v4] fast-(import|export): improve on commit signature output format

[Christian Couder <christian.couder@gmail.com>]

On Tue, Jul 8, 2025 at 6:38 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Christian Couder <christian.couder@gmail.com> writes:
>
> > Also if a contributor comes back with improved patches that try to
> > follow closely what a reviewer suggested, then I think it can (and
> > should) make a reviewer feel like they have really been heard better
> > than just a hollow reply right away followed later by less well
> > thought out patches.
>
> That is kind of "better late than never".  I would expect better
> than that from more senior prominent contributors ;-)
>
> And I totally agree with you that reviews often deserve very well
> reasoned responses, which take time to prepare; a response that
> comes as spinal reflex without much thought is often not very
> useful.
>
> It really depends on the definition of "fast" in "fast response".
>
> If we need a week to come up with a newer iteration,

The issue is that whatever the time we could set as a norm, like "a
week" here or 2 or 3 days, or one month, or whatever, we actually
don't know what happens in the life of contributors. Maybe some have
health issues, maybe some work only a few days per week, maybe some
oare working on their free time and don't have much free time, maybe
they are asked to work a lot by their company on other internal urgent
things, maybe they have to take care of dependent people in their
family, etc... So setting any norm here that everyone should try to
respect might just not work for some people.

For example there was a former Outreachy intern who continued working
for about 2 years on their project after the internship was over. She
was a young mother so didn't have much time to work on Git and would
come back to the mailing list only every few months with new patches
and replies to reviewers. What would we have gained exactly by
imposing a norm on her?

> it would be
> fair to expect that we can say something like "I agree, I'll fix",
> "I am not convinced because ...", "I am skeptical but let me first
> see how it pans out", etc. by day #2 or #3, wouldn't it?  Upon
> recieving a response at the same time or soon after an updated
> iteration was sent, especially when the response is "no, I do not
> think so", what is the reviewer expected to do?  Saying "you may not
> think so but here is another point that may make you reconsider"
> would be too late, so it would actively discourage continued
> discussion.
>
> > It doesn't mean that I think oldtimers should have some kind of
> > privilege, and yeah they should also try to give a good example. But
> > we should allow people to not always behave in a very formatted way.
>
> Old timers learn from experience how other old timers operate ;-)
> and I have learned to ignore the usual signal when anticipating what
> your next iteration may look like (in other words, interim responses
> or lack thereof is usually a good signal for most developers, but
> not for you---you tend to come back with your next iteration without
> much interim interactions).  But other contributors shouldn't be
> forced to. That is what we need some community norm for.
>
> >> On our team's handbook page [1] we have the following couple of bullet
> >> points regarding how to respond to reviews:
> >
> > Yeah, I think they are likely to be good for newcomers.
>
> The handbook here is gitlab's team handbook, and it may not apply to
> open source Git development community, but "this rule applies only
> to newcomers, I am above that rule" is the same thing as saying
> "oldtimers like me should have some kind of privilege".  I do not
> know what to think about this and what you said above.

I think it's fair to say that oldtimers are less likely to disappear
tomorrow or to not follow up on reviewer feedback. So arguments like
"replying fast makes reviewers confident that they have been heard"
are just less true for oldtimers than for newcomers.

Another argument is that oldtimers are more likely to burn out or have
mental health issues related to their Git work than newcomers. Adding
a norm that would put pressure on them to work more, or at times they
would prefer to do other things, significantly increases the burnout
and mental health risks for them.

So putting pressure on oldtimers to follow a norm that is less
relevant for them but puts them at greater risk is just a bad idea in
my opinion.