If you submitted an application to Ruby Central in the Google Summer
of Code and it got rejected, you may be wondering what you can do.

For one thing, don't get too upset: it isn't personal. We received 84
eligible applications, but Google only sponsored 10 of them. Bad news:
if you were of the 74, you got rejected. Good news: you had about a 1
in 8 chance of being selected.

So how can you increase your chances next year?

Here is what I suggest, in order of importance (keep in mind this is
my personal opinion and is not necessarily Ruby Central opinion):

1. Don't submit a Rails-related application. I know Rails is popular
and is driving a lot of Ruby's momentum right now, but still, it was
Ruby Central that got chosen by Google, not Rails Central (or whatever
organization might represent Rails.) Myself and the other mentors
would certainly look at Rails-related applications, but they sort of
were automatically demoted because they generally are not applicable
to Ruby in general. This especially applies to web apps written in
Rails, because besides being written in Ruby these have almost nothing
to do with Ruby or improving it in any real way.

In addition with all the momentum it has, Rails seems to have plenty
of willing volunteers for fixing bugs and adding features. Whereas
Ruby has many needs which go unfulfilled. Those are needs that we
wanted to address with SoC.

2. Be original. Of the 10 top applications which are being sponsored
by Google, only one even remotely resembles one of the ideas on the
Ruby Central SoC ideas page. I know this seems counter-intuitive but
since Ruby is a programming language there is a lot that can be done,
so we don't have the same focus and solid list of objectives that
other SoC projects might have.

3. Describe concrete deliverables. One of the most frequent
suggestions made by myself and the other mentors was for the student
to be more specific in deliverables in the application. I think the
ideal would be a week-by-week breakdown of work. This is detailed
enough to show the student has thought about the problem, without
being so detailed that it is unrealistic in trying to predict the
future.

4. Be better known in the community. If I saw an application from a
student who I had seen on ruby-talk, or whose projects I was aware of,
they were automatically raised in my eyes. Having a proven track
record of code is a great indication that a student will deliver some
value in a SoC project.

5. Don't use the Google template. I saw a lot of applications where
people just filled out the template in a very rote, boring way and it
got old reading those after a while. It shows some lack of creativity
and initiative to just fill out the form. I would recommend using the
template just as an example of the kind of information that might be
useful, but don't provide everything just because it was asked for.
Only 3 of the 10 final applications used the template.

6. Submit early and revise as needed. It pains me to say it, but the
applications that came in earlier got a lot more attention than ones
than came in much later. In a perfect world all would have gotten the
same attention, but the reality is after reviewing 30+ applications,
the last 50 which come in over the last 4 or 5 days can get
overlooked. We mentors are people and can get a bit tired after a
while.

7. Proofread yourself and have someone else check too. This is last on
my list because it isn't the most important thing, but it does make a
difference. This isn't an English contest and I know not everyone is a
native speaker, but if the application is hard to understand, the
mentors are less likely to look upon it kindly. Plus communications
skills are important in distributed development like you see in open
source projects.

So there you go, ideas to keep in mind for next year. I'll probably
post this somewhere else as well, and assuming Google continues SoC in
2007, I'll post it again next year.

Regards,
Ryan