Do you have the time?

This is most important IMO. You need  to have time to spare to be able to talk to the student, to assist him if he needs it, to look at the reports and give advice and feed back on the current status of his work. Being a mentor does not mean asking the student to "Report to me everyday" and then replying with a three lettered email that goes "ACK". It is much more than that. Mentoring is an active task, be it for the GSoC or Fedora Ambassadors. One needs to be available, all the time. You are taking a student under your wing. It is your duty to help him complete his task. If he fails to complete the GSoC, it is as much your fault as his. It is also your duty to back him, to speak for him if required. This is how relationships are forged in FOSS: out of respect for each others' work, and as you get to know each other better, out of respect for each other.

If you consider mentoring to be a passive role where you sit back and watch, please, stay away.

Are you well versed with the work involving your idea?

Well, you can't know the all the tiny details, obviously. However, are you qualified enough to be able to do the task yourself? "Why?" you ask? It's rather simple. The idea is yours, you think it could work. Why did you think it could work? Did you do your research? Did you read up on the capabilities of the libraries you suggest using? Yes, the student will do his own research, but like I wrote earlier, you are the mentor. By definition, a mentor guides the student. How would you guide someone if you yourself are ignorant of the process? Ask your self this: "If the student gets stuck, would I be in a position to bail him out? If not, do I know people who'd have time to do the same?".

Is your idea long term or short term?

The coding period at GSoC is May 21 to August 20. That is three months of solid work. However, successful projects aren't made in three months. Tasks, therefore, are generally specific to a certain area of a project. They may be enhancement implementations, or bugfixes, or optimizations and the sort. Even though these tasks are specific, they have consequences in the long term for the project (rather, they should have consequences in the long term).

I guess what I'm asking you is: "In the long term, will the work done in this GSoC period be counted on?". If the answer is "Yes", you should go ahead right away! If the answer is a "No", I suggest you rethink your idea and plans. An idea that receives a "No" on this question shows lack of planning. It shows that there isn't a follow up plan for the work the student will do. Remember that the student is only responsible for the work done in the three months of the coding period, for the work he planned under your guidance. The follow up plan is more your responsibility than the student's. The student, who will generally be new to the project, is not to be assumed capable of making long term plans for it.

The gist of it all

I guess what I'm really trying to put across is the importance a mentor holds. A mentor can make or break a GSoC project. A mentor can make or break a potential contributor to the project. A mentor can even make or break the entire project. It is not a role to be taken lightly. The student relies on you. I do agree that FOSS follows a mostly self learning paradigm. We don't like to spoon feed people. However, we do point them into the correct direction, be it a man page, or just google. As a mentor, you should have the time, the knowledge, the sincerity, the morals to direct your student. You are very much accountable.

Having pointed out the serious bits, GSoC is a lot of fun! I enjoyed it thoroughly last year as a student. From the fedora mentors, I hear they enjoyed it quite a bit too! Let's get some ideas on the board people!