Probability of acceptance of pull requests

I had a really bad experience trying to use node.js for a project. Eventually I figured out that the module I needed was just broken, so I decided to at least update the documentation. As it turned out, not only was it not documented how to update the documentation (...) but I had to go back and forth on undocumented style guide rules (for documentation that gets displayed in the browser anyway!) and then sign the CLA, all to update a single line of text in the docs to say 'don't use this module, it's broken'. It literally would have taken less time for them to make the change themselves.

This soured me even more on node.js than actually using it had. It's bizarre that project maintainers would actively put so many walls between themselves and valuable (or not-valuable, for that matter) code contributions.

I can only assume that the legal downside to not having a CLA signed for every single-line commit is enormous. Are there previous court cases in the US where not having a CLA got someone destroyed?

When there are multiple independent discussions spawned from different parts of single patch, as is common in less disciplined communities, the granularity of email is too coarse, and threaded line-comments are much better. On the other hand, patches on mailing lists frequently spin off into higher level design/philosophy discussions, which isn't appropriate in line comments.

    $ git fetch url-or-remote their-branch-name:my/better-branch-name
    $ git checkout my/better-branch-name
    $ hack, commit, etc

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.