I strongly believe that everyone, and I mean everyone, is ready to contribute to OSS. On the Python project, Jesse Noller recently started a "core mentorship" group to help people put the rubber to the road. There's an almost endless amount of work to be done on CPython, and we'll literally take anyone with any amount of knowledge and help them contribute. Whether it's people contributing to OSS for the first time, or people new to contributing to Python, we can find something.
If you understand English, you can write documentation. If you can write Python code, which is obviously a common skill for someone interested in contributing to Python, there's plenty of work. If you know C, dig right in.
The group of core contributors ranges from 18 to the upper 60s, from the self-taught to multi-PhDs, from students to Googlers. I think the only people who aren't ready to contribute, wouldn't be interested in contributing in the first place.
> It’s not obvious where to start.
This is definitely an issue for a lot of projects, and as mentioned above for CPython, the core mentorship group is hoping to tackle this.
Online and in person, I've pointed countless amounts of newcomers to the "easy" bugs list on our tracker, but that's not always a great starting point. Half of the issues are a 35 comment bikeshed, but it's tagged as "easy" because the end result will probably be a 2 line change. The other half of the issues are easy, but in uninteresting corners of obscure modules.
I've had success leading newcomers at the PyCon sprint to start with test coverage, and I think that approach worked pretty well. You can't get too far without writing tests anyways, so it's a good educational step that you can even take back to your day job if you aren't already doing so. Additionally, it's a task that gives you a tangible sense of accomplishment. Being able to fix bugs is cool, but often they are very low impact. Being able to say you raised test coverage from 30% to 70% is nothing to shrug at.
Having early success is key to having continued fun on the project. No one wants to spend their evening working on a patch to have it rejected and shot down -- that's not fun. My approach, and one I also suggest to some first-timers, is to start with documentation. You can bang out 10 successful doc patches a lot easier than you can do 10 successful code changes. In order to get some attention to yourself, find the easiest way in the team and stick with it a bit before branching out.
> Guidelines often make a maintainer’s life easier, and mine harder.
I can certainly feel for this, and speaking for CPython, I think we've tried to keep the guidelines simple and well documented. Overall, the process doesn't deviate too far from "write it, review it, commit it", when it comes to being an external contributor. Once you have commit access, some of the source control process gets hairy, but it mostly stays out of your way and lets you do the work.
> Open source is for people who are better at this than me.
I'd put myself on the bottom of the pile both on the CPython team and at my day job. I told my dad programming was stupid when I was in high school, I barely got by in college, and finally found myself the first year on the job. I'm not a bad developer by any means, but I'm not blowing the doors off of companies when I interview with them. I just like what I do and I have fun doing it -- I think a lot of the people involved in this stuff are probably the same way.
> Trying to contribute and failing makes me feel stupid.
Failure sucks, straight up. It especially sucks when it's on an open source project that you're trying to help in your free time outside of work. It's not news that you're going to fail from time to time, but something that worked for me and apparently some people I've helped was choosing the right thing to work on. I touched on it earlier, but fixing 5 small easy things sometimes looks better to a maintainer than fixing 1 regular thing. If you start with that approach, soon you'll have 15 successful pull requests and may feel more confident to dive into deeper and harder things, and the maintainer may have more confidence that you can offer quality work for those harder things.
> There’s no time.
Time is the biggest bottleneck in open source. Not only do you have a kid, job, and responsibilities, everyone else does too. Submitting a patch or a pull request only to have it sit un-noticed for months sucks. The only way to get it through the system is more time. I don't know of any really good solutions on the maintainer side other than quitting everything and going full steam on the project, but that's clearly not viable :)
> It’s pretty lonely.
The CPython core mentors group aims to fix that. I don't remember the numbers off the top of my head, but the ratio of core contributors to new outsiders is pretty tight, and we've helped a bunch of interested contributors get their work accepted. Your average 1-man project might not be able to do this, but we've tried to make a group available for those who need a helping hand on Python.
I have created several bug reports for Django where I pointed where it fails and even offered "bad" solutions in the description. I rarely provide a true patch because I don't have the latest of Django and rarely have the time to check it out, create a patch and tests. In the few cases that I have, my patch hasn't been used because the developers, in the wisdom, found better solution, usually very similar to mine, but more thought out or handling other cases I wasn't aware of. This doesn't bother me, because the developers are never hostile over proposed solutions, in fact they have been appreciative for the help in a starting point.
You (and this Python Mentors program) totally rock. It's hard to even name all the things the program gets right.
This is one of the most encouraging things I've read in regards to getting my finger out and starting to give something back. You've sparked my interest and I will definitely be looking at this and seeing how I can contribute and get involved.
The bar is a lot higher than that. You have to understand English and understand the functions themselves. Sometimes even getting bullet-point list of functionality out of devs is like pulling teeth - leaving you with nothing to document in the first place. Similarly an understanding of why something was designed a certain way helps angle the documentation more accurately.
Clean documentation is hard, and doubly so if you're not the person who wrote X module for OpenFoo.
In general, you're certainly correct. I was thinking too much about Python, where there's a strict but easy to follow guideline that all public APIs are documented, so the lowest level work has already been done. Because of that, there aren't a ton of places where you'd need a super deep understanding of the code in question to make a documentation impact. A lot of it is updating, removing, and reformatting. You'll see a lot more "reformat this paragraph as a table" issues than "write the whole doc for the wizbang module", the former being a fairly easy task.
Even though it seems python specific, it can be used almost verbatim for other project.
Double Thumbs Up.
After you are setup there, http://bugs.python.org/ is the bug tracker. Bugs are sorted newest first, and there are a bunch of queries on the left side of the page, plus a query builder. The search feature works fairly well, and I sometimes suggest that people search modules they are comfortable with. If you use zipfile a lot, search it, and you'll find 46 issues.
In addition to that stuff, as Jesse mentioned in one of the responses, http://pythonmentors.com/ is the mentor site. There's a mailing list you're more than welcome to join should you have any questions, comments, or anything about the process. We can help you get setup, help you figure out what to work on, and help you successfully contribute your work.
Will be nice if Perl can also do this. This will help Perl 6 efforts a lot.
More here: http://www.kde.org/community/getinvolved/
Feedback welcome, we're only getting started.