What is a CLA and why would a project want one / not want one? They seem like another hurdle for contributors?
Searching for "sign cla", it appears to be a Contributor's License Agreement.
Probability of acceptance of pull requests
11–20 of 57 posts
Re: Probability of acceptance of pull requests
#12What is a CLA and why would a project want one / not want one? They seem like another hurdle for contributors?
Re: Probability of acceptance of pull requests
#13The title is a much more cynical take on the data than I have looking at it. I have some familiarity and experience with Django, one of the projects that has a pretty low pull request acceptance rate from his sample. At 29% I was impressed that many pull requests were accepted, frankly! I think the signal to noise is pretty high on pulls to high profile projects. It's easy, and common I think, to throw a small change…
well, I guess adding anything to settings.py will get red flags instantly because everyone is sick of settings, that is common knowledge when you follow django-dev and con vids. my almost first contribution to django was recently hijacked by a better one, bummer :)
Yeah, it was a long shot. I thought maybe the fact that it was entirely optional and not on by default might help my case, but the reasons for it being turned down were totally reasonable and consistent with the project & python idioms.
Still, I ended up building our own shell command that included the change because fuck typing that much.
Re: Probability of acceptance of pull requests
#14great analysis. I thought big projects have a lower acceptance rate than smaller ones in general, but when you take a look at django vs flask to rails vs sinatra, it doesn't seem to be the case. one nitpick: next time rotate the diagrams +90' please :)
> one nitpick: next time rotate the diagrams +90' please :)
What? No. The x-axis is the independent variable and the y-axis is the dependent variable.
Re: Probability of acceptance of pull requests
#15What is a CLA and why would a project want one / not want one? They seem like another hurdle for contributors?
It's a contributor license agreement. "Contributor Licence Agreements (CLAs) can be used to enable vendors to easily pursue legal resolution in the case of copyright disputes"[1].
Licensing/copyright can be a messy thing - especially with multiple authors involved. I assume the legal clarity it provides is seen as worthy of the extra hurdle to some of the more risky and/or cautious projects. Plus, depending on the agreement, it allows more freedom for change of license terms without getting all existing contributors to agree - the agreements I've signed have often contained a clause declaring implicit permission (or waiving rights completely).
[1]http://en.wikipedia.org/wiki/Contributor_License_Agreement
Re: Probability of acceptance of pull requests
#16great analysis. I thought big projects have a lower acceptance rate than smaller ones in general, but when you take a look at django vs flask to rails vs sinatra, it doesn't seem to be the case. one nitpick: next time rotate the diagrams +90' please :)
> one nitpick: next time rotate the diagrams +90' please :) What? No. The x-axis is the independent variable and the y-axis is the dependent variable.
tell that to my neck.
Re: Probability of acceptance of pull requests
#17The title is a much more cynical take on the data than I have looking at it. I have some familiarity and experience with Django, one of the projects that has a pretty low pull request acceptance rate from his sample. At 29% I was impressed that many pull requests were accepted, frankly! I think the signal to noise is pretty high on pulls to high profile projects. It's easy, and common I think, to throw a small change…
It's so much better to send these sorts of proposal via e-mail. It's much easier to review the patches via e-mail, and everyone on the development community can make suggestions. Even so, it's not uncommon for patches to require three or four versions, and not just by first-time contributors. There are patches written by folks who have been working on ext4 for many years which still require three or four or more revisions after being subjected to multiple rounds of peer review.
If you show me a git project where most of the pull requests are accepted, I'll show you a git project whose quality assurance is probably completely out of control.
Re: Probability of acceptance of pull requests
#18Re: Probability of acceptance of pull requests
#19The curious question is why certain projects have significantly lower pull-rates; I doubt the quality of the pull requests vary that widely across projects. Is it that project leadership has a clear vision for a product and feel pull requests are a distraction? If so, share the vision and enlist willing developers to help achieve that vision. Is it that project leadership has a high-standard for the codebase? If so,…
> The curious question is why certain projects have significantly lower pull-rates; I doubt the quality of the pull requests vary that widely across projects.
The reverse is more prevalent. The quality of projects varies wildly. The higher quality the project, the less likely that you can accept a pull request as-is.
> Is it that project leadership has a clear vision for a product and feel pull requests are a distraction? If so, share the vision and enlist willing developers to help achieve that vision.
Most developers seem to expect to throw code over the wall in a pull request, and do not follow up to requests for improvement to meet the project's requirements, eg:
- Testing requirements
- Documentation requirements
- Code style
- Ensuring that the implementation fits into the broader project road map
- Code quality
- Avoiding code duplication
- Avoiding code-to-the-goal solutions (see also: project road map).
In my experience, most pull requests take more time to review and correct than it would take to write the code in question from scratch.
> It does take effort and planning but the net result is so worth it to all parties involved.
I don't think the economy is there, actually. Either people are going to read your contribution guidelines and provide quality material, or they're not. Most of the time they're not.
Given my (15 years of) experience in open-source, I'm highly suspect of code quality those projects that have acceptance rates above 50% from people other than core developers.
Re: Probability of acceptance of pull requests
#20The title is a much more cynical take on the data than I have looking at it. I have some familiarity and experience with Django, one of the projects that has a pretty low pull request acceptance rate from his sample. At 29% I was impressed that many pull requests were accepted, frankly! I think the signal to noise is pretty high on pulls to high profile projects. It's easy, and common I think, to throw a small change…
It's so much better to send these sorts of proposal via e-mail. It's much easier to review the patches via e-mail, and everyone on the development community can make suggestions. Even so, it's not uncommon for patches to require three or four versions, and not just by first-time contributors. There are patches written by folks who have been working on ext4 for many years which still require three or four or more revi…
Does this hold true for you on smaller projects too? Ruby gems, for instance...?
I personally strongly prefer to see a diff via Github, especially for smaller features on a small library / gem -- although on larger & more popular projects (lots of pull requests) it definitely makes some sense that you'd prefer to have a 'heads up' of sorts via email first to confirm that it's even a desirable feature.
Really just wondering here, I recently started semi-blindly submitting pull requests with feature additions or small bug fixes (with very verbose pull request messages + solid but concise commit messages) to various library-type projects so I'm legitimately curious as far as how far to take this logic...