3 ms·

> TBH the time taken to write the final correct patch would be a fraction of the time needed to explain how to write a better patch. This is always the case fo

> TBH the time taken to write the final correct patch would be a fraction of the time needed to explain how to write a better patch. This is always the case for a senior developer dealing with a junior developer. Basically your argument is that junior developers shouldn't try to contribute and if they do, they will just be rejected out of hand if they make any mistakes. Okay. > But I wonder whether that's true for OSS projects in general. A person randomly shows up to report and attempt fix a bug in an "obscure"(?) architecture -- this is not a junior who just joined the team, and they have no commitment to stick around to do more contributions. If you treat people like crap, they won't stick around. So it is a bit of a self-fulfilling prophecy. I think that great OSS leaders are few and far between. One that I can think of that I've worked closely with for a decade is mrdoob of Three.js. Humility, openness, focus and good people skills. I cannot approach his skill set here, and in part that is why I respect it so much. He achieves a lot and there are hundreds of contributors to Three.js of all different skill levels. And he definitely is not going around rewriting simple PRs just because he can and instead he and others are coaching and encouraging the community. This is why Three.js thrives. I think this particular OSS developer isn't leader and is more of an individual contributor type who doesn't collaborate well. That is okay. It is unfortunate that his behavior is reflecting poorly on the Linux project, but that is who he is.

hnfong 3y ago
> Basically your argument is that junior developers shouldn't try to contribute and if they do, they will just be rejected out of hand if they make any mistakes. Okay. I don't think that's as wrong as it sounds. There are projects and codebases that are more or less "done" (and heading towards obsolescence) and aren't worth it to expend resources for juniors to learn how to work on them. It's usually much more rewarding to have junior developers try to implement something "new" instead of fixing obscure bugs on a stable codebase. There's much more leeway for mistakes in new features, there is less/no learning curve to grok the intricacies of the existing code, and fewer surprising edge cases that the juniors would inevitably miss because they haven't been stung by it 10 years ago. As I mentioned, it's up to the projects themselves to decide how much they want to expend extra resources in bringing up potential new contributors. As with most things in software engineering, it's a trade off. And yes, the OP feeling angry with the way the kernel maintainer handled this issue could be said to be a trade off as well. I think the only thing that's unfair about this discussion is that you and maybe a hundred others are making claims about the kernel maintainer ("isn't leader", "behavior reflecting poorly on the Linux project", "treat people like crap") for allegedly misattributing credit for a less than 20 line patch. Imagine a minor mistake you made 1.5 years ago making the front page of HN and hundreds of people slinging insults at you. I wonder how that feels. Quoting from you: > If you treat people like crap, they won't stick around.
arp242 3y ago
> I think that great OSS leaders are few and far between. We can also revert this and say that great contributors are "few and far between". Collaboration, patience, and empathy is a two-way street. Could the maintainer have done better? I guess; I would have done things a bit different. Then again, maybe their dog died that morning and they were in a foul mood? I'm not joking: people aren't perfect, they have good and bad days for all sorts of reasons, etc. Everyone makes a mistake now and again. But whatever this maintainer could have done better, this blog post also isn't a good look: sour grapes a year and a half later and making a big deal out of what is really a singular minor personal conflict (and with some misrepresentations to boot). Now, maybe the author's dog died this morning, so I'm not going to attach any far-fetched conclusions about this person, or about Cisco, because again, everyone has bad days and no one is perfect. Making a big deal out of any mistake or conflict is also toxic, as is making rather strong conclusions about a person based on a single event.
- bhouston 3y ago
  > But whatever this maintainer could have done better, this blog post also isn't a good look You are correct, I definitely would not have written that blog post either. > Making a big deal out of any mistake or conflict is also toxic, as is making rather strong conclusions about a person based on a single event. I believe what you are describing is formally called the Central Attribution Error (CAE.) https://ethicsunwrapped.utexas.edu/glossary/fundamental-attribution-error https://ethicsunwrapped.utexas.edu/glossary/fundamental-attr... You are right, I should edit my original comment to remove my speculations that are probably based on CAE but it is now locked for editing.

hnfong 3y ago

> Basically your argument is that junior developers shouldn't try to contribute and if they do, they will just be rejected out of hand if they make any mistakes. Okay. I don't think that's as wrong as it sounds. There are projects and codebases that are more or less "done" (and heading towards obsolescence) and aren't worth it to expend resources for juniors to learn how to work on them. It's usually much more rewarding to have junior developers try to implement something "new" instead of fixing obscure bugs on a stable codebase. There's much more leeway for mistakes in new features, there is less/no learning curve to grok the intricacies of the existing code, and fewer surprising edge cases that the juniors would inevitably miss because they haven't been stung by it 10 years ago. As I mentioned, it's up to the projects themselves to decide how much they want to expend extra resources in bringing up potential new contributors. As with most things in software engineering, it's a trade off. And yes, the OP feeling angry with the way the kernel maintainer handled this issue could be said to be a trade off as well. I think the only thing that's unfair about this discussion is that you and maybe a hundred others are making claims about the kernel maintainer ("isn't leader", "behavior reflecting poorly on the Linux project", "treat people like crap") for allegedly misattributing credit for a less than 20 line patch. Imagine a minor mistake you made 1.5 years ago making the front page of HN and hundreds of people slinging insults at you. I wonder how that feels. Quoting from you: > If you treat people like crap, they won't stick around.

arp242 3y ago

> I think that great OSS leaders are few and far between. We can also revert this and say that great contributors are "few and far between". Collaboration, patience, and empathy is a two-way street. Could the maintainer have done better? I guess; I would have done things a bit different. Then again, maybe their dog died that morning and they were in a foul mood? I'm not joking: people aren't perfect, they have good and bad days for all sorts of reasons, etc. Everyone makes a mistake now and again. But whatever this maintainer could have done better, this blog post also isn't a good look: sour grapes a year and a half later and making a big deal out of what is really a singular minor personal conflict (and with some misrepresentations to boot). Now, maybe the author's dog died this morning, so I'm not going to attach any far-fetched conclusions about this person, or about Cisco, because again, everyone has bad days and no one is perfect. Making a big deal out of any mistake or conflict is also toxic, as is making rather strong conclusions about a person based on a single event.

bhouston 3y ago
> But whatever this maintainer could have done better, this blog post also isn't a good look You are correct, I definitely would not have written that blog post either. > Making a big deal out of any mistake or conflict is also toxic, as is making rather strong conclusions about a person based on a single event. I believe what you are describing is formally called the Central Attribution Error (CAE.) https://ethicsunwrapped.utexas.edu/glossary/fundamental-attribution-error https://ethicsunwrapped.utexas.edu/glossary/fundamental-attr... You are right, I should edit my original comment to remove my speculations that are probably based on CAE but it is now locked for editing.