Be Foresighted: Include a full plan of action with your proposal, about one half to a full page of what you're going to do and how you think you will do it, and possibly even what you will do if your initial approach does not work.
Be Documented: Include academic references, as links or brief quotes, which back up your ideas. That kind of stuff impresses us. On the other hand, do not include 15 pages of reference materials; we won't read it. Summarize.
Be Known: If you know anyone in open source who can vouch for your code quality and/or diligence, use them as a reference.
Begin: Projects related to research already in progress at your school are good; it allows us to evaluate your approach, as well as giving us the assurance that you are serious about your topic and have already done background work.
Be Involved: Several students have already pitched their ideas to the pgsql-hackers mailing list. We like this; it shows that the student already understands how our community works, and is more likely to get their patches accepted.
Be Early: We expect to receive 50 to 100 applications for five to eight spots. Applications which we get on the first day of the application period will get more attention from the mentors, and thus more chance of being accepted, than applications which show up on the last day.
Be Specific: Your proposal should include specific, well-defined deliverables and timelines. "Fix the query planner" is bad. "I expect to take 10 weeks implementing a new n-distinct algorithm for better rowcount estimation and integrating it into the PostgreSQL planner." is good.
Be Bold: suggest innovative and ambitious approaches to solve hard problems. Ultimately, we're looking for new major contributors for our projects and a bold proposal makes us think you might be a candidate. Yes, we offered up the TODO list as ideas, but stuff that we'd never thought of before got moderated up even if it didn't get accepted.
Be Realistic: SoC requires you to complete a project in 3 months or less. So don't be so bold that your proposal can't be finished. One proposal we rejected almost immediately said "As a whole, I think this idea is too large to be pulled off by one person in 3 months." We agreed.
Be Original: Many students submitted nearly-identical proposals based on recent "hot" papers on ACM and similar academic publications. For example, we got 3 separate proposals for an XML datatype using CTrees. If you do make a proposal based on a current "hot area" in CS/DBMS design, then make sure to make another unrelated proposal as well, because you'll have plenty of competitors.