Probability of acceptance of pull requests

Is it possible to switch the axis and set the maxima at 100%? I have to re-calibrate for each graph, or 30% almost looks like 50%. And it's hard to read the rotated labels, but the percent on the horizontal axis would not need to be rotated.

We require contributors to sign a CLA before accepting pull requests to RethinkDB (http://github.com/rethinkdb/rethinkdb) for several (excellent) reasons, explained here: http://www.rethinkdb.com/community/cla/

We've found that it's a low hurdle for contributors-- it's a common attribute of most open source projects and helps avoid headaches of ownership later on down the road.

Essentially, no project wants the question of who owns contributed code to come up. The SCO-Linux controversy would have been avoided if a CLA had been in place, and since then they've become standard practice.

The x-axis data is not numerically ordered, so there's no good reason to keep it oriented that way.

I can't speak for the other projects, but the data is completely wrong and misleading for jQuery. It looks like this code only counts a pull request as merged if it's landed with a merge commit. It's much more common for us to touch up the pull request (for example, fixing small style or commit message issues), then rebase, possibly squash some commits, and land via a fast-forward commit.

So this is "accepted": https://github.com/scalatra/scalatra/pull/267

But this is not: https://github.com/jquery/jquery/pull/1255

This is a complicated problem, and one that I'm excited to think could be improved in the coming years as Github et al have the time and resources to invest in it.

I have a few thoughts on the topic and on your comments:

1. I actually DO think that the quality of pull requests varies widely from project to project. You dismiss this in your first sentence but I don't think you should. I think there are a lot of reasons for this, but many can be reduced to: Some projects attract more inexperienced developers than others.

2. I don't think you can simply indict the project maintainers for not optimally leveraging the talent pool of volunteer contributors. While Open Source has been validated a million times over as a truly successful movement/concept/etc, nobody has ever accused it of being efficient. Specifically, most pull request submitters act on their own, without coordination between submitters or with project maintainers. It's not just an issue of coding standards, it's also things like the maintainers having a roadmap that includes bug fixes, refactoring, new features, etc, and that may conflict with Joe in Idaho and his pull request that he did to scratch his own specific itch.

In many ways community submitted pull requests are a "million monkeys at a million typewriters."

3. The most successful way of getting a pull request accepted, I think, is to first raise a discussion on the issue on the projects mailing list or issues forum. Link to your in-progress patch, say "I have this fix here for problem X, can anybody take a look and tell me if I'm on the wrong track with this?" So many of us are code-first, conversation-later types and that constantly conflicts with the social nature of our job.

I guess my takeaway here is that there is a lot of room for interesting technology solutions to this problem, in the areas of:

1. Tools that help maintainers cultivate the submitters talent pool on their project.

2. Tools and workflows that help submitters through coordination. Totally a half baked idea but suppose if I'm fixing a bug in a function somewhere, Github can help me discover what is happening to that function elsewhere. Maybe it's been radically changed in a feature branch owned by the project maintainers, maybe it's already been fixed nearly the same way by another submitter who has an open pull request, maybe it was already submitted by somebody and rejected.

3. Static analysis that can power those tools and more. Would love a meaningful quantative quality score on the pull request submission page. Like an additional tab beside the "Commits" and "Diff" tabs. Maybe it could run various analysis on the code and show formatting issues, known vulnerabilities, known bugs, etc. Obviously the abilities here vary from language to language.