
The Pull Request Hack - felixge
http://felixge.de/2013/03/11/the-pull-request-hack.html
======
steveklabnik
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.

~~~
headius
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.

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

------
wuest
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!

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

~~~
kibwen
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.

~~~
typicalbender
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.

~~~
weaksauce
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.

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

~~~
snprbob86
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.

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

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

~~~
chocolateboy
> 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>

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

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

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

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

~~~
bhaak
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.

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

~~~
yuvadam
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.

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

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

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

------
snarfy
It's how Tom Sawyer paints a fence.

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

------
aaron695
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...](https://fosdem.org/2013/schedule/event/challenges_libreoffice/)

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

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

