Christian Couder <christian.couder@xxxxxxxxx> 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.
