Please Send A Patch
Recent Debian blog entries with this title (by Lucas Nussbaum, Matt Palmer) point out assortedly that:
- Existing developers frequently know the code base so much better than newcomers that they’re likely way more effective at improving things than some callow newcomer.
- Taking those developers’ time to do your pet thing instead of something they find useful mayn’t be more effective.
Both points are quite valid, and recent PostgreSQL CommitFest activity suggests a way to at least try to evaluate things.
The PostgreSQL project has a number of committers that are unusually productive developers (-1 from me, Tom? 
), and there have certainly been times when the “best” outcome has been for someone to come in suggesting ideas, and for one of the notably productive folk to implement it.
But there has been some debate surrounding the 2011-01 CommitFest, which consists of some 98 proposed patches, all of which require review. These are all, in fact, patches that came as some sort of response to Please send a patch . The trouble with this particular CommitFest is that the patches have been overwhelming the reviewers in terms of sheer volume. Developers that should be considering working on their own “pet features” have been drawn into the review process to look at others’ features instead. None of these results are inherently a bad thing, except for the aggregate that falls out, which is that there’s so much stuff outstanding that it’s tough to get them all properly reviewed.
If a project is busy and vital, it’s pretty necessary for people to do a fair bit of “scratching their own itches” (in keeping with Matt Palmer’s comment) in order to grow the community of people capable of giving real assistance to managing the code base.
“Growing community” requires that some people struggle with the code base a bit so that they become familiar enough to become effective in the future.