If I see a developer who has contributed to many oss projects, I don't think "wow this guy must be a great programmer", I think "this guy must have great communication/people skills".
Often (especially with popular oss projects such as apache, python, firefox), you can fix a bug, add it to the ticket tracker, and it'll just sit there and rot. Every day people fix bugs and upload patches. You have to contact someone and sweet talk them into merging your fix.
> If the original title begins with a number or number + gratuitous adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."
And that usually requires the skin of a pachyderm, and the patience of a fox. The reality of today is that the world idolizes idols. Idols in turn become arrogant. Their worst trait is belittling others' contributions - especially when they're better than the rock star could've done.
I have no solution. I'm pointing out what I see as an omission from an otherwise useful post.
What kind of things? Everything from sane documentation to artwork is open and in need of lots of help in many projects.
Here in Korea, a lot (probably majority) of people who contribute to open source started from i18n, l10n, and translation.
The daunting part is the time commitment.
OpenHatch is a non-profit dedicated to matching prospective free software contributors with communities, tools, and education.
I, myself, have begun more thoroughly documenting projects, not only for my sake but for everyone else that comes along. I find that this book helped me get up to speed quickly: http://www.amazon.com/The-Elements-Style-4th-Edition/dp/0205...
We had a pretty big discussion in #parrot about the value of this ticket set. People on the project plowed through the Trac database and closed tickets, and even with that we still hundreds that tracked all sorts of development. Many were bug reports, and many were effectively to-do items, and many were bug reports that had been resolved but still couldn't be closed for various reasons, such as needing an automated test to verify it.
It's nice to start over clean, but sometimes there's too much baby with the bathwater.
Thank you for the article, BTW. It may be obvious to some but not to most. Especially contributing to documentation. I'd say that most open source projects can benefit more from that than from new features ... and maybe even most bug-fixes, depending on severity.
Agreed about documentation, and at the top of my to-do list for today is making final edits to another article for them on open source documentation. Should be out in a week or two I think.