Spicy take: I kinda agree that pull requests to major mission critical open source projects like the Linux kernel should be limited to people who are signing up for developing on it like hundreds of hours a year. It can't be on the maintainers to manage endless drive by pull requests - especially in the era of slop commits from every dork with a Copilot subscription. Let new blood cut their teeth on smaller less mission critical projects first.

@JessTheUnstill

Yes and no.

I think the Linux kernel has a different issue overall. Except for drivers; the majority of the issues inside the Linux kernel are huge infastructure projects. (the exception might be improving the BPF verifier where a new person could in theory help out especially when you say this is a sequence of BPF ISA that should be accepted; how do we improve value tracking to accept it). Ok there could be some tunining of some scheduler heuristics but that is always going to be rejected; the scheduler has always been a pain (Witness folks quiting Linux kernel over it 10 years ago or maybe even longer).

This is unlike say LLVM or GCC where you could have very small projects (a day or a week) which can be done for optimizations.
The other side of things testing GCC or LLVM is much easier and is actually existing.

So I agree with your statement about the Linux kernel but that is only because unlike a compiler it is only driver development (ok fine there is more to the linux kernel than driver development but that is where the majority of people working on the Linux kernel get paid for).

@pinskia @JessTheUnstill there are small tasks to do in Linux, it's just a big software system so there's always small things that need fixing. I think the real difference is how Linux is managed: it's not really a single project, it's more of a group of more-or-less coupled projects that are all stored in a single git repo. That makes finding small projects much harder, as there's no single place to look.

So in practice the smaller tasks end up getting handed out to the development teams that are active in each of these sub-projects, and for active sub-projects those tend to be just a few teams spread between a few interested companies (that mostly know each other pretty well).