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