A post from David Anderson to the GSoC-discuss list sums it up pretty well:

Speaking as a mentor, I'd at least like to see in a proposal some
understanding of the challenges and steps involved in accomplishing
your task. I want to be sure that you understand what it is you're
signing up for, in terms of work. Saying that you're confident you can
accomplish the task means nothing if you haven't understood what the
task involves :-).

To that effect, one of the things that works best for me is a rough
timeline. Show me the big steps of your project (granularity of 1-3
weeks), and how much time you intend to spend on each. That gives us a
clear impression of whether you know in which general direction you
should be going, even if the details are still fuzzy. It also tells us
how much time you estimate each component will take, which helps us
figure out if you can actually make it work in time.

A little preliminary design work is also welcome, if you're designing
a new feature, since it shows that you've already dug into the code
and design of the project a little bit. For instance, if you were
adding a feature to a program, you could say "It seems that part of
the functionality of the frobnicator is already present in the pilfer
grommit subsystem. I propose to first extract that functionality into
an internal library that can be reused by both the frobnicator and the
pilfer grommit. Then, I will work on expanding that library's
functionality and API to meet the needs of the frobnicator, before
starting on the UI code." It shows that you've poked around a bit, and
have a rough plan of where you want to go, even if you don't yet have
a specific API in mind for the internal library, or for the UI you
plan to build (though it might be a good idea to have a few key ideas
for UI, if your task requires one).

We're trying to encourage students to interact with us here, or via IRC/email/IM/whatever to help refine and develop their proposals before submitting them through Google.

- Rob :)