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

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