It's kind of weird that they, in general, picked HUGE projects like Python and Ubuntu, rather than dinky projects where an additional coder or two could make a big impact.
My general guideline is "work on what you use" or "work on what annoys you", ie:
Find a typo or inaccuracy in a man page? See about fixing it.
Need an extra feature in a program you use? Add it and see if the maintainer wants it.
Have a new/novel use for a tool? Blog about and promote it.
Don't set out with the goal of "I'm going to contribute to X" - contribute to a lot of things and see where you're useful.
If the target is first-time contributors, then I would say a consistant process, for them, trumps the potential contribution to the project.
My experience with "dinky" projects is they are inconsistant with accepting help (bug reports, code, features, etc). It is extremely discouraging when you send a pull-request and watch as it sits there for 8-10 weeks without being addressed or acknowledged. Larger projects have a more consistant process, and more consistant/prompt feedback, which is ideal for first-time contributors.
i think you're a little spoiled from pull requests. you used to have to format patches according to coding standards(in fact still do in many projects), and then have a lengthy discussion on why your code sucks. you could argue that that's very discouraging, but I disagree.
> and then have a lengthy discussion on why your code sucks
That is the kind of feedback I would hope for. The issue is the lack of any feedback from the maintainers on "dinky" projects. If I, as a first-time committer, filed a pull-request, and it still had 0 comments after 90 days, I would feel discouraged.
this is probably the most important, and at the same time straightforward advice anyone can get.
The most successful companies start out like this. Some of the most powerful open source projects started like this.
Most importantly this is probably the most powerful way to learn something. As opposed to say a programming assignment in school saying that you should write a point of sale terminal so Fritz Miller can buy his 3 tomatos 2 apples and 2 pizzas.
We're kindred spirits, my friend. Load the page on a 13" rMBP and the title of the article is only just barely above the fold - pushed down by a monstrous header with ads for... more articles? But I clicked this article! I wanted to read this fucking article right here!
Firefox is a huge project, but it is open to new contributors, has good documentation about contributing, and is written in many different programming languages. "Bugs Ahoy" is a search engine that will filter Bugzilla bugs marked "[good first bug]" by programming language or feature area:
the choice of projects seems somewhat arbitrary. i've only contributed to one (python), but i can definitely say that many of these codebases are total messes (drupal, libreoffice for sure) which would make me _not_ want to work on these projects. in reality, the easiest way to get introduced to open source is to start your own projects to build the kind of reputation and experience necessary to contribute to bigger projects.
Although I don't agree with the list, the metric they applied is a good one: does the project actual welcome contributions? I mean, nearly everyone says they do, but the reality is rather different.
They probably should have recommended you stay away from GNOME, as well.
Or make contributions to something you use that is small and self contained.
All the examples here seem way too big to get started with IMO. Take "Ubuntu", it covers so much! You're better off fixing bugs upstream in the individual projects that interest you than rushing headlong into the Ubuntu bureaucracy-fest.
Dunno about Drupal or LO. The latter did have a lot of publicized cleaning up done recently. Might be better nowadays? Still a massive codebase though.
Python seems like the "easiest" contender - it compiles without many dependencies in a few minutes on a fast machine, and has good docs - but the article already hints that there's not much low-hanging fruit left.
While the choice of suggested projects seems completely arbitrary, my issue is with the "Stay away from the Kernel part."
My fist ever contribution to an open source project was a silly little patch for the Kernel. While there was some initial indifference on the mailing list, Greg Kroah Hartman patiently guided me and after four iterations finally pulled in my patch.
True, there are more than a few grumpy Kernel hackers, there are also loads of folks willing to help out newbies. You know, like in ANY opensource project. Hell, there's a website and an awesome mailing list just for newbies!
No. Sorry, had to work with Drupal 6 for 2 years. Made me quit my job. That's one hell I want to avoid, even when they do switch to symphony. No hard feelings.
At one place I worked a number of years ago, one of my colleagues, who was always the first one there in the morning, had the job of getting Drupal running and some extension/module/plugin/whatever installed and hacked up in order to carry out some task. He was not really happy with it, to put it mildly, but managed to get things working.
When I left the company, I set up a cron job on my computer to randomly play an .mp3 of me saying DRRUUUUPPPAAAALLL during the early hours of the day when he was there. I guess he just about wet himself the first time he was sitting there alone and heard it, the way he tells it.
Instead of those arbitrary picks, how about looking at Google Summer of Code?
Those projects have conveniently listed what things they want help on and already have allocated mentors to lead those projects.
While you might not be a student, if you really want to help out, I bet most of those projects would welcome additional involvement and the mentors would be willing to talk with you if you are serious about helping.
The criteria here is opaque, and doesn't necessarily make sense. If you're talking about "open source project to use due to ease of use", Ubuntu might be in the top ten. Maybe. But if you're talking about an open source project to contribute to because the "community is huge, international, and diverse", and "the project offers a wealth of online documentation to help new contributors get started", that sounds like Debian, which is what Ubuntu (and countless other) distributions are based on. On top of that, if you don't like the default desktop, not only is it easy to change for you, but the Debian developers are much more likely to listen to your input on the defaults. What's more, if you find something wrong in Debian, in any part, you can get the source and fix it. Can't say the same about Ubuntu with it's binary-only drivers.
All Drupals aside, I think Python and PostgreSQL were wise additions. Aside from the friendliness of the projects to newcomers, think of what being a regular contributor to either project will do for your job prospects. I don't want to hire the person who knows PostgreSQL - I want to hire the person who's helping to write it.
My general guideline is "work on what you use" or "work on what annoys you", ie:
Find a typo or inaccuracy in a man page? See about fixing it.
Need an extra feature in a program you use? Add it and see if the maintainer wants it.
Have a new/novel use for a tool? Blog about and promote it.
Don't set out with the goal of "I'm going to contribute to X" - contribute to a lot of things and see where you're useful.