Tips on writing your proposal
Be detailed. Don't say "I want to improve Python's support of XYZ", because that's vague, making it difficult to assess the project's feasibility or the time required. What changes would you make to improve XYZ support?
Be early. We received about 200 proposals in 2006. Proposals submitted earlier receive more attention and can go through more revisions than proposals submitted right before the deadline.
Compare with alternative projects. If your project will do task XYZ, look at other existing projects that perform the same task and explain how yours is different or better. (Or you can write a proposal to enhance an existing project instead.)
Try to provide a rough timeline. How much time would each change take (a day, a week, six weeks)? What intermediate milestones will there be? (e.g. for a game, you might get an initial graphic display in week 1, write a parser for level definitions in week 2, write a level editor in weeks 3 and 4, etc.)
Remember that mentors need a way to see that you're making progress (or that you need help), and we need to report to Google part way through. A request for specific deliverables and a timeline was by far the most frequent comment on proposals this year. Many proposals fell out of contention because they were missing this portion, and didn't revise their proposals soon enough.
Get feedback. Post the proposal to a relevant mailing list and ask for comments. Post the proposal to your weblog and see what people think.
Describe your experience. Why are you a good person to work on this project? What skills/interests/knowledge do you have that are applicable?
Get some experience. If you have some presence in the project before the Summer of Code proposals are due, it greatly improves your chances. Show up in March or April and contribute patches or fix bugs on the codebase you want to work on.
Suggest a mentor. If you know a developer who would be a good mentor for your project, contact him/her and ask if they're interested. In 2005, some interesting projects went unfunded because there was no one in the pool of mentors who felt capable of handling them.
Describe the Benefits to Python. If a neat application has no particular tie to python except that it was written in python -- that is OK. We still like it, and we could probably find a willing mentor. But when we have to prioritize which good projects to fund, these applications will suffer.