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.
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.