How to contribute to open source without being a programming rock star
softwarequalityconnection.com
softwarequalityconnection.com
I disagree. I find that politely rejecting or rewriting contributions from people with little experience or clue is a serious time drain for a maintainer (as well as a trial of patience). This goes even for documentation, which, when written by people without a clear view of the software, tends to be confused and misleading.
I try to handle such contributions gracefully anyway, with the idea that some of these people will use the feedback to grow into better programmers, but even that is unlikely to benefit the project -- the time span it takes to go from clueless to good is probably longer than the period in which the person is involved in my project.
I don't agree with your assumption that "the time span it takes to go from clueless to good is probably longer than the period in which the person is involved in [the] project." If I can spend some time shepherding the new person, who is probably more naive than unqualified, it will pay off in spades later.
And I say that after having done some of it here and there.
{meta} the guidelines ask to avoid "14 ways to" style headlines, and to have instead "Some ways to" or even just "Ways to".
I'm going to be expanding all of them into a website that will have a page for each of them.