The Pull Request Hack | Hacker News Reader

The Pull Request Hack

felixge.de

198 pointsfelixge34 comments

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.

I think we just have different tolerance levels for this kind of thing, but we've talked about it in person, so you know this. :)

This is a clever bit of social engineering which really taps into the mentality, not to mention the rhetoric, of open source hackers. I like it!

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.

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.

That could still be gamed by committing a lot if you are a malicious user. I'm sure they could figure out a way that would work but it seems the naive way is Not ideal.

Also remember that you can trivially fake author name, email and date in git and thus github. Only the github-side push log will tell which user pushed what, the commit log can lie all it wants.

Most notably, you can backdate a commit and github won't even show it in the commit log (because it uses strict commit date order).

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.

You don't need to rewrite history. You just add new commits with fake author & date.

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.

Do you know about the compare view?

http://jbuckley.ca/2011/09/githubs-compare-view/

http://zachholman.com/talk/git-github-secrets/

Quoting from the article:

So should you really do this for all pull requests? Probably not. While I've given a large amount of users access to various projects of mine, I'm still looking for:

- Github profile: Does this user stand to lose a reputation by doing something stupid?

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.

> This is similar to how the Rubinius project has been managed for a long time

... which in turn was "taken from Audrey Tang's commit policy on Pugs". [1]

[1] http://jacobian.org/writing/commit-bits/#c2548

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 not accept pull requests. Let the other person maintain their own fork and accept pull requests to their fork.

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.)

In a first step you can have a descriptive branch name for your default branch and if you feel you need to go further you can rename your repository.

Isn't this enough?

For really popular forks you can often see that in the members tab many sub forks have forked off them. This is a good hint for a project that has left the original repository behind.

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.

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.

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.

Unfortunately not, this is the one big missing feature from GitHub.

How is this different from having your own fork?

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.

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.

It's how Tom Sawyer paints a fence.

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. :)

I've done it before, it's a great way to kill a project.

Sounds like a interesting story, why not value add and say more about the issues?

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.

https://fosdem.org/2013/schedule/event/challenges_libreoffic...

Reply on news.ycombinator.com