I'm of the opinion that the best thing for large projects is new blood. If large OSS projects rotated people through triage and new contributor on-boarding, e.g. how to make a patch, how to get it approved, and so on, then in the long-run the number of contributors will grow.
But how do you do that without occasionally handing over the maintainership of some important piece of infrastructure to someone who clearly can't handle it? The people at the top of the ladder right now are there because (and sure, there are exceptions) they are (1) very good at it, and (2) willing to do it. And they have employers who have made bets on those two facts. Those employers aren't really interested in someone else taking over when they have someone working now.
I'm sensitive to this, really. I work in an embedded linux world where I end up submitting a bunch of patches to various projects as an "outsider" (often one who is still learning the project in question). And yeah, I get yelled at a lot. And it sucks.
I'd love these people to be nicer too. But honestly I don't see a "process solution" like you propose. We just need to find nicer hard-working ubergeeks. I'm not holding my breath.
There is a very very simple but quite useful technique which should be easily automated: send an e-mail thanking the contributor for the pull request and telling him with courtesy that it may be left to oblivion due to lack of time.
Honestly, for any OSS project leader this should be easy.
All of us know the difference after sending a CV anywhere between:
-1) destroying answer (do not send us your CV anymore)
a) NO answer
b) Automated answer without politeness intent
c) Polite automated answer
d) Personalized, human-written answer
You cannot do d) always but you should certainly do c).
I'm making two assumptions here: firstly that there is a hierarchy of contributors, where triage doesn't have to be handled by the guys right at the top; and secondly that the first few submissions by a new person aren't major--they are going to attempt something small first. If the latter isn't the case, the response should be "sorry, we appreciate your help, but try to get some minor bug fixes in before a major architectural change".
That's actually not the way the real world works though. The primary "jerk" projects (mostly the kernel and Linux infrastructure) are dominated by submissions from paid, professional developers working on support for new features for their employers. These people are routinely coming from closed-source backgrounds, don't understand the project, don't write new feature with an eye to maintainability, and have an affirmative requirement from their managers to get their submissions accepted. As I mention, sadly, I'm in this set more often than not.
That's just not a recipe for fun. The "hair trigger rejection" filters are there because of all the junk that gets thrown at the maintainers. And either it makes them grumpy or is acceptable only to people who don't mind being rude. Either way, the "jerk" bit is a direct correlation.
