[gresrun]

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.

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, explicitly state the standard and provide constructive feedback to pulls that don't quite measure up.

I guess my point is: project leadership has the ability to leverage a tremendous pool of talent that is interested in their project using the pull request mechanism. It does take effort and planning but the net result is so worth it to all parties involved.

[encoderer]

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.

[gresrun]

> Some projects attract more inexperienced developers than others.

Fair.

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

I strongly disagree with this assertion. To argue that community cannot be lead or directed toward a common goal is very pessimistic. Sure, Joe in Idaho has a specific itch, but there's a good chance there is an opportunity to capture Joe's enthusiasm and willingness to do work on the project by working with him instead of treating him like a code-monkey at a keyboard. Community relations is hard because dealing with people is hard.

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

Yes, I agree that this is someplace where some tools would help tremendously.

> Github can help me discover what is happening to that function elsewhere.

Great idea. I'd love to see a "related diffs" tool for a given piece of code.

> So many of us are code-first, conversation-later types and that constantly conflicts with the social nature of our job.

I totally agree. Ultimately, tools will only get us so far; people skills must fill in the rest. Making "Joe" feel welcome and a part of the creative process requires measures of patience, kindness, gentleness and mentorship.

[anonyfuss]

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