On Thu, Jul 10, 2025 at 2:01 PM Patrick Steinhardt <ps@xxxxxx> wrote: > > 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: > > > 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. Ok, so how are we going to manage those exceptions? Are we going to ask people publicly why they take a long time to reply, and expect that they are going to tell everyone things that might be quite personal? How will they feel if they are asked repeatedly by different reviewers, in the case some reviewers didn't notice that other reviewers have already asked? > 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. They could fall into similar groups. They could have a child they take care of, they could have health issues (including burnout) or they could just have a few bad days sometimes. They could also stop being employed to work on Git and still want to contribute. Are we going to have a public list of people who are allowed to reply late, so that every reviewer can check if it's Ok for the contributor to reply late? > 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. So you think it would be good for the community if people start to keep count of how fast others reply and annoy them when they don't reply fast enough? In my opinion, insisting on this is just a bad idea that could backfire in many ways. I am not saying that it wouldn't be good if people in general tried to reply soon to reviewers when they receive feedback. I am saying that it's not worth the possible costs to insist on this small aspect of what makes reviewers happy. > And leading by example in this > context also means that they should encourage healthy discussions. Why is it not healthy when contributors reply when they think it's best for them to reply? It seems to me that, on the contrary, it's not healthy to put pressure on them to reply when they might not think it's best for them to reply. Responding soon is in my opinion a very small part of what makes discussions healthy. There is also the tone, the thankfulness, the constructiveness, the technical accuracy of the information shared, the work that might have been done to try solutions, the willingness to share knowledge, the effort to try to understand and act on what others say, and so on. Reducing the quality or healthiness of discussions to just how fast a person replies, is just not a good metric. It's like measuring how productive a person is by counting the lines of code produced. > 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. You could also say "it should be possible for most people outside any special circumstances to 'produce' 20 lines of tested code per working day". Would that make it worth measuring and annoying people in case the measure is not up to the norm? > 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. What kind of expectation? Do you mean that the resulting code after review, or even before review, should be way better too? Even when the person employed might be a junior programmer while there are very experienced contributors working on Git in their free time? And if for example someone retires from work and then starts contributing to Git 10 hours per day every day of the year, then should people employed to work on Git try to match that amount of working hours? If someone working on Git in their free time has an especially good mastery of the English language and starts to write awesome commit messages that are on average 100 lines long, then are we going to expect people employed to work on Git especially those who are not native speakers to do as well in this regard? People are just different in many different ways, and what you might very well expect trivially from some, might be very difficult for others. > > 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. People often are good in some ways and bad in others. You cannot expect all old timers to be perfect examples in every way. And that should be fine. > > 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. My opinion is that in cases like this, there is no norm that works for everyone.
