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