Linus has said this a few times -- in general they don't actively try to onboard new contributors.
There was in fact a talk given by Greg Kroah-Hartman, one Linux's lead maintainers, about development for the Linux kernel which he titled "I Don't Want Your Code".
He's at Linaro, specfically taking their developers to task for sending bad patches. And they indeed sound horrible, but he's good natured about it.
I'm just starting to accept patches for my project, and honestly I'm flabberghasted that people will send patches that not only don't run, but don't build. And Greg was saying the same thing.
I guess I got spoiled at my last job, where people generally sent high quality patches / code reviews. Although toward the end, I noticed some sloppiness. It wasn't the main reason I left the company, but it started to feel like the downfall... I don't want to work with people who don't know how to submit code reviews / patches.
Indeed, I've seen the same thing. I have considered automatically rejecting any patch made with the GitHub online editor (obvious because the committer name is always GitHub). They are pretty much invariably of shit quality.
This _might_ show a long-term risk for Linux.
I get the feeling most people who complain about how "clunky" email is have never actually tried to submit a patch to LKML. If I could figure it out when I was a high-school student, a professional developer should be able to figure it out as well.
The linked article explains at length why it works well for kernel maintainers. And since it does, why should kernel maintainers change it just to make things easier on newbies? It's much more reasonable to expect new participants to adapt to a workflow that works, than vice versa.
This is not "gatekeeping," it's just the reality that not everyone works the same way.
If you won't submit a kernel patch because you feel that email is unfashionable, then you're kind that should be kept out of the gate. Sorry.
No, the former is enough. It shows that whatever their programming abilities they are prone to bike-shedding, so they are better avoided.
Also we are arguing backwards here. They don't make it intentionally hard to keep out new contributors, it's just not important in any way to make it simpler. The goal is to make it work best for the thousands of existing contributors, especially the gatekeeping subsystem maintainers.
Generally yes, but IIRC Linus has explicitly said that he likes the process being intentionally hard to keep out new contributors.
I'm not so sure. If the kernel development was on Github, I may have looked into contributing, but as it stands, its not worth the trouble to try to contribute (as I don't have anything specific to help with). And, I suspect there are more capable developers who are closer to the edge than me.
Anyway, having a slightly lower bar to get started may not get more developers involved, but instead my get them involved more quickly.