# Summer of Code Advice For Ruby Central Applications

**URL:** <https://www.ruby-forum.com/t/summer-of-code-advice-for-ruby-central-applications/61573>\
**Category:** Ruby\
**Created:** [May 25, 2006, 3:55am UTC](https://www.ruby-forum.com/t/summer-of-code-advice-for-ruby-central-applications/61573 "2006-05-25T03:55:00Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![lazukars](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/eb9ed0/32.png) [@lazukars](https://www.ruby-forum.com/u/lazukars)\
**Post date:** [May 25, 2006, 3:55am UTC](https://www.ruby-forum.com/t/summer-of-code-advice-for-ruby-central-applications/61573/1 "2006-05-25T03:55:00Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![lazukars](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/eb9ed0/32.png) [@lazukars](https://www.ruby-forum.com/u/lazukars)\
**Post date:** [May 25, 2006, 5:56am UTC](https://www.ruby-forum.com/t/summer-of-code-advice-for-ruby-central-applications/61573/2 "2006-05-25T05:56:16Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![lazukars](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/eb9ed0/32.png) [@lazukars](https://www.ruby-forum.com/u/lazukars)\
**Post date:** [May 25, 2006, 5:59am UTC](https://www.ruby-forum.com/t/summer-of-code-advice-for-ruby-central-applications/61573/3 "2006-05-25T05:59:37Z")

</div>

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

Michael