This policy works for young or small projects. It does not work for larger, more complicated projects.
On the JRuby project, we carefully examine all incoming pull requests. At least half of them would break something unintended, and half of the remaining non-breaking PRs aren't done properly, don't match our style, would perform badly...and so on. Giving out commit access to people based on one PR and a bit of background information is not sufficient.
The problem here is one of expertise. Very few people in the world have what we need on the JRuby project. You need to be fairly meticulous about what you commit, running tests, understanding the codebase. Ideally you need to understand what's involved in building a language runtime. Just because you're a good contributor to other projects doesn't mean you're going to be a good contributor to JRuby, and we won't give out commit access to unproven devs.
Ultimately, the reasons people give for handing out commit access are almost completely trumped by Github's ability to fork repositories. You can basically fork, do multiple PRs and changes over time, and never really require commit access to be a good contributor. And we will potentially add you as a contributor if your results are solid over time (or steadily improve to where we're comfortable adding you).
My last statement on this is that I don't think I want people on the project that aren't willing to put together a good PR or patch until they're given commit access. The kinds of folks I want contributing are the ones willing to submit multiple fixes over time, willing to learn our codebase and standards before joining the team, and who have a vested interest in seeing JRuby remain solid and improve steadily.
On the JRuby project, we carefully examine all incoming pull requests. At least half of them would break something unintended, and half of the remaining non-breaking PRs aren't done properly, don't match our style, would perform badly...and so on. Giving out commit access to people based on one PR and a bit of background information is not sufficient.
The problem here is one of expertise. Very few people in the world have what we need on the JRuby project. You need to be fairly meticulous about what you commit, running tests, understanding the codebase. Ideally you need to understand what's involved in building a language runtime. Just because you're a good contributor to other projects doesn't mean you're going to be a good contributor to JRuby, and we won't give out commit access to unproven devs.
Ultimately, the reasons people give for handing out commit access are almost completely trumped by Github's ability to fork repositories. You can basically fork, do multiple PRs and changes over time, and never really require commit access to be a good contributor. And we will potentially add you as a contributor if your results are solid over time (or steadily improve to where we're comfortable adding you).
My last statement on this is that I don't think I want people on the project that aren't willing to put together a good PR or patch until they're given commit access. The kinds of folks I want contributing are the ones willing to submit multiple fixes over time, willing to learn our codebase and standards before joining the team, and who have a vested interest in seeing JRuby remain solid and improve steadily.