On Wed, Jul 09, 2025 at 02:19:06AM +0200, Christian Couder wrote: > On Tue, Jul 8, 2025 at 6:38 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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, > > 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? There are always going to be exceptions, that is of course true. But I also think that long-time contributors that are employed to work on Git are somewhat special and don't (typically) fall into the mentioned groups. From my perspective, it's especially this group of people that should lead by example and encourage others to behave in a way that is good for the overall Git community. And leading by example in this context also means that they should encourage healthy discussions. That of course doesn't mean that such people should always respond within an hour, or even within a day. We all have to context switch, and context switches are costly, so it's entirely reasonable to try and minimize them. But outside of any special circumstances (vacations, health or similar) I think it should be possible to engage in such discussions within a small handful of days. In any case, there of course is a distinction between people employed to work on Git and those that do it in their own free time. The expectation that is extended towards people who work on Git is way higher than the expectation extended towards people who don't. > > 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. I think these are two different things. It's probably true that you get some privileges by being an old timer. But I think it's more in the sense of "You get to tackle bigger things that may not be done in a single patch series, and we trust you to not just disappear". But with that privilege also comes responsibility. It's those old timers that newcomers look to, so they need to lead by example. > 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. This is of course something we must avoid. Nobody is being helped in case people burn out. There needs to be a middle ground that works for everyone. Patrick
