I think the bigger problem here is that Github is rather useless at gracefully abandoning a project. The usual solution is for an interested maintainer to fork the project and continue, but with any sufficiently popular project it's impossible to tell which forks, if any, have momentum.
I feel like there's got to be a middle ground between the current "fork in obscurity" model and the OP's "commit bits for everyone" model. But I'm not smart enough to think of what that might entail.
I like the idea Github providing an easier way to gauge momentum on a repository and then maybe do some sorting based on that. I can't tell you how many times i've been looking for a repository and a large number of them come up with no indication, other than number of starts and forks, about whether that is the main repository that is still maintained or not.
Yes, but also remember that you'll get loud warnings about non-fast-forwards thanks to the cryptographically secure SHA1 hashes. This means that the repo admins and downstream clones can trivially detect history rewrites for branches they have fetched. Unfortunately, there isn't a good way for code-consumers to tell if and when a non-rewrite commit or branch has been "blessed" by an admin rather than some random committer. I guess this means that the README should make some mention of the collaboration policy and the admins should preserve release power to whatever the relevant package manager is.
but with any sufficiently popular project it's impossible to tell which forks, if any, have momentum.
Seconded. This is one of the pain-points I wish github would address. The constantly broken "network graph" and complete lack of (meaningful) tools to compare forks or branches is a royal pain in the ass.
Many of the missing operations ("In which branches does commit X exist", "Show delta between A,B") shouldn't even be hard to implement.
I don't understand why github spends their resources on useless gimmicks ("streaks", "pop repos") rather than pushing their core product.
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.
I wish Github made it easier to capture the fact that forks often diverge and become their own distinct (but related) projects. Right now you have to email support and ask them to detach the fork, which detaches everything from the previous graph of forks & commits.
(The graph is important -- Often when I find a useful but less-than-maintained project, I search the graph to find a fork that is better maintained.)
The cool part of the hack isn't that you do this for projects you're no longer maintaining - it's that you give others commit privilege for projects you _are_ maintaining. OP's point was this empowers others by giving them ownership of the project, and leads to better work.
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.
I suspect this hack isn't about access control, since that effect is already achieved with pull requests on forked repo branches, but rather with the social hack of giving a person responsibility over mainline code, and having her maintain the project much better herself.
I do this on all my personal projects now. It's pretty amazing. I've actually gained several long-term contributors by doing this.
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."
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.
You can't make a rocket scientist just by giving them carte blanche to play with rockets. I definitely appreciate the empowering aspects of open commit policies, but I'm less concerned with getting contributions than I am with getting good contributions. We've even added some committers prematurely over the years...and those came after months of patches and PRs.
The primary bottom line for a larger or more established project is maintaining code quality, stability, predictability of behavior...all while still moving forward with new features. When you endeavor to achieve those goals in every commit, giving any PR-sender the keys to the castle doesn't seem like such a great idea.
As I mentioned elsewhere (and to you in discussions about open commit policies), I also don't feel like there's a good reason when Github makes it so easy to fork projects. We've worked with some folks for years off forks. I'm also not thrilled with the idea that you're going to get good developers if your developers only "really" started contributing once they got a commit bit. Just because someone's excited to drive a race car doesn't mean they're qualified.
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.
Old HN link but libreoffice is trying a similar thing.
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.
I think the first 5-10 mins of the video is the important bits.
Cool. I believe this works on the same principle that employee stock options does. Empowerment.
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.