A lot of the argument you’re making here hinges on the idea that patches involve a higher degree of effort than comments. However, I’ve found that the “edit on github” model severely undermines that. I’ve gotten patches on Node.js, npm, and many other projects, where the JavaScript isn’t even valid, causes failing tests, doesn’t compile, etc. In other words, the user has not even downloaded and run the code that they’re sending, not even once.

I exchanged the position of two variables that should have loaded in a different order.

Long story short, I’m largely disinclined to submit patches for anything ever, unless I personally know the author(s).

Defending a patch that takes something from “entirely broken” to “hey, this works and is beginner friendly” is not something I want to do again. Nobody was particularly rude, but the stress chemicals weren’t worth it.

Perhaps I should grow up and grow thicker skin. At any rate my “story” is anecdotal, probably best ignored. 😉

My most successful open source projects have adopted the policy that 1 accepted patch gives you commit rights to the main repository. I’ve found that the most unlikely people often become key contributors. Much better than designating people as members of a “core team”. Instead to breath life into an opensource project you need patches. I don’t want to spend all my time maintaining a project. I often have the energy to start something, but if no one else has the energy to maintain it, it will eventually die. Recruiting energy givers by accepting patches is the key way to help ensure that an opensource project does not die.