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

[Junio C Hamano <gitster@pobox.com>]

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