GSoC - Deadline for Student Proposal

May 3rd was the deadline for all proposals from students who wanted to participate in the 2013 Google Summer of Code. We received an amazing 79 proposals,which kept our mentors certainly very busy. A big thank you  to all our mentors for their tireless and patient work they did over the last two or three weeks. They were constantly answering questions, giving feedback, and helping students to get started. I have over 600 GSoC related emails during those three weeks (not counting those on the google list), and according to my log files talked to more than 30 people in private chats. It got quite frantic towards the end. Here the list of proposals per day:

In contrast to what we heard before the proposals mostly had a rather high quality, we didn't receive many 'spam' proposals (e.g. proposals completely unrelated to SuperTuxKart). Google had changed the number of proposals a student can submit from 20 to 5, and this might be responsible for this: less opportunity for students to 'spam' mentoring organisations with bad proposals (and since it appears we had an above average number of proposals we were even less likely to be targeted by those, since the chances for a bad proposal with us would be even worse).

Some of the proposals were extremely long and detailed (one proposal had 18 pages in an attached pdf file). Not that we expected that much detail in the proposals, but it shows how much effort some students put into their proposal. And most of them also reacted positively to feedback we gave them, so a compliment to the students at this stage as well.

Here some common problems we noticed so far:

• Not having the right level of description: Stating that you are going to 'write a battle AI using some existing path finding algorithm' isn't really enough to tell us how your code is supposed to work. Path finding was only one part of that project, how does this work with all the other missing parts? On the other hand, a list of function names and parameters does not tell us how those functions are supposed to work together. That part is the important part, we don't need to know about function names here. 
• Not understanding the project. Many people used encryption/signing to make sure that replay files saved from SuperTuxKart can not be altered, completely forgetting that it's trivial with an open source game to modify the data written before it is signed.
• Untested patches. Some of the patches appeared to have not been tested, and did not work as expected. If you replace a printf warning message with our new Log::warn(...) interface, you should at least test that this warning works as expected, and not only if it compiles: do something to get this warning printed, and make sure it works as expected.

We are probably not able to provide individual feedback on all proposals, but I intend to write a follow up blog post detailing some of the common problems for certain ideas, and in general some other things we noticed. Hopefully we will be able to publish some of the better proposals as an example for everybody later.

It will be another few days before google lets us know how many slots (students) we are going to get. Then we will be busy for the next two weeks to read and rank 79 proposals, and pick the final selection of students. But one thing is already obvious: we have many more good proposal than we will get slots in the best case.