I do this on all my personal projects now. It's pretty amazing. I've actually gained several long-term contributors by doing this.<p>I've gotten emails from people that said, in effect, "Thanks! I feel like part of the team, that you trust me with the code. Before, I was just going to fix that one bug, now, I'm excited to poke around the codebase and see how I can help."<p>Really, this is a variant of a theme that we see around here all the time: autonomy, mastery, and purpose. The upside is that you empower people to take mastery over the code they use, you provide them with the autonomy a commit bit has to offer, and you give them a sense of purpose: you're now helping everyone else out, too.
I'd be wary of this policy becoming the norm. It would be pretty easy for malware authors to hijack useful-but-neglected projects by submitting moderately helpful pull requests.
This is similar to how the Rubinius project has been managed for a long time: After your first pull request gets merged, you'll be added to the repository as a committer.
Wikipedia works even though everyone can commit by default, anonymously. Obviously there is some difference when people are downloading code and running it, and Wikipedia has its own kinds of problems with edit wars. Collaborative software development should look at the social and software structures that let Wikipedia stay useful. (not that this hasn't already gone both ways)
It makes complete sense: people submit patches as "proof of concept", to show that a fix is possible, and how to go about it. It's not laziness or lack of ability, it's just that there's no need to handle exceptional cases in a proof of concept.
Needless to say, when you're actually patching the code, then you start worrying about the details, so it makes complete sense.
This is pointless. If your fork is no longer maintained you should say so and <i>not</i> accept pull requests. Let the other person maintain their own fork and accept pull requests to their fork.
Wouldn't it be better to set up an org, transfer the project to the org and add someone else? That way you can even transfer administrative jobs like commit access to others.
Does Github support branch-level access control? If so, a maintainer could keep control over the master branch to control what gets merged into a stable release but allow developers to run with a development branch and feature branches.
This policy works for young or small projects. It does <i>not</i> work for larger, more complicated projects.<p>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.<p>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.<p>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).<p>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.
Cool. I believe this works on the same principle that employee stock options does. Empowerment.<p>In another situation, it is also generally good practice to let employees know you think highly of their work. Most people will try to live up to this expectation even though it might not necessary be true.
I've been a user of projects where the maintainer basically merged everything. A lot of stuff was broken. The only good thing was that it was easy to get my fixed merged. :)
Old HN link but libreoffice is trying a similar thing.<p>The video doesn't go into enough detail IMHO but the TL;DW is they are making it easier to commit and putting automated processes into place to mange it(Like extensive and easy testing). Rather than a commit is hard philosophy.<p>I think the first 5-10 mins of the video is the important bits.<p><a href="https://fosdem.org/2013/schedule/event/challenges_libreoffice/" rel="nofollow">https://fosdem.org/2013/schedule/event/challenges_libreoffic...</a>