Summer of Code Advice For Ruby Central Applications


#1

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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


#2

Ryan L. wrote:

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

Wow. That kicked ass.

Informative, detailed (but not verbose), and well-written.

Thanks. (I didn’t have an SoC submission, but making it easier for
people writing submissions in the future will help others help Ruby to
improve. That’s a Good Thing.)


James B.

“Simplicity of the language is not what matters, but
simplicity of use.”

  • Richard A. O’Keefe in squeak-dev mailing list

#3

Yes, nice write up Ryan. You’re a good communicator.

Michael