WritingASummerOfCodeApplication
Version 3, changed by rcoup 02/28/2007. Show version history
We've compiled some advice here for how to go about writing a Summer of Code application. Good luck!
How to write a Summer of Code applicationSell your idea. Describe your idea in detail. What is its ultimate goal? What components will it have? What benefits does it have for Dojo and its community? How do you plan to achieve completion of your project? Sell yourself. Get across your enthusiasm for the project. Tell us what makes you stand out from the rest of the crowd. Talk about your past experiences, what makes you tick. Why are you interested in open source software, and Dojo in particular? What interests do you have, and how do these interests relate to the project for which you're applying? There is a basic assumption that people applying for Summer of Code will have at least some programming skills already. So rather than spend a lot of time elaborating on these (though by all means, do tell us what you know), spend time talking about you. Show enthusiasm. Summer of Code is an exciting opportunity, and Dojo is cool. We're not just looking for people who want a summer job to pass the time, we're looking for devoted people who are excited about AJAX and about open source, and are (or will become) regular Dojo contributors. Tailor your application to the project. Some people may send applications to more than one project, and copy/paste large chunks of text from one application to the next. That's a mistake. Each application you send should be targeted and tailored for the specific mentoring organization and project to which you are applying. Get feedback on your idea from the community. Discussing your idea with some established Dojo folks is vital. If your idea duplicates existing efforts or code (and does not provide a very convincing reason for doing so), it will be rejected. Try to have your application reviewed by someone before you submit it, whether that be the mentor for a particular project itself (in the case of ideas listed later on this page), or a person with expertise in a certain area (such as the vector drawing, or RDF). Don't be afraid to ask the community for help; we want you to succeed just as much as you do. :) Don't be afraid to go out on a limb. Have a brilliant idea that's not covered by the proposals on the following pages? Great! Don't be scared to try and think "outside the box" and come up with a fantastic idea of your own. |
The above text is based on Drupal's HOWTO: Write a Summer of Code application, by Angie Byron and Karoly Negyesi. The original text, and this modified version, are released under a Creative Commons Attribution-ShareAlike 2.0 license. |
| Be detailed. Don't
say "I want to improve Dojo's support of XYZ", because that's vague,
making it difficult to assess the project's feasibility or the time
required. What changes would you make to improve XYZ
support? Be early. We received about 20 proposals in 2006. Proposals submitted earlier receive more attention and can go through more revisions than proposals submitted right before the deadline. Compare with alternative projects. If your project will do task XYZ, look at other existing projects that perform the same task and explain how yours is different or better. (Or you can write a proposal to enhance an existing project instead.) Try to provide a rough timeline. How much time would each change take (a day, a week, six weeks)? What intermediate milestones will there be? (e.g. for a game, you might get an initial graphic display in week 1, write a parser for level definitions in week 2, write a level editor in weeks 3 and 4, etc.) Remember that mentors need a way to see that you're making progress (or that you need help), and we need to report to Google part way through. A request for specific deliverables and a timeline was by far the most frequent comment on proposals this year. Many proposals fell out of contention because they were missing this portion, and didn't revise their proposals soon enough. Get feedback. Post the proposal to a relevant mailing list and ask for comments. Post the proposal to your weblog and see what people think. Describe your experience. Why are you a good person to work on this project? What skills/interests/knowledge do you have that are applicable? Get some experience. If you have some presence in the project before the Summer of Code proposals are due, it greatly improves your chances. Show up in March or April and contribute patches or fix bugs on the codebase you want to work on. Suggest a mentor. If you know a developer who would be a good mentor for your project, contact him/her and ask if they're interested. Describe the Benefits to Dojo. If a neat application has no particular tie to Dojo except that it was written using Dojo -- that is OK. We still like it, and we could probably find a willing mentor. But when we have to prioritize which good projects to fund, these applications will suffer. |
| Based on advice written by Andrew Kuchling and Jim J. Jewett at the Python Project, and included here with Andrew's permission. Here's the original PostgreSQL advice. |
| Be early. Applications
received in the beginning of the
submission process get a lot more attention than those received in the
last hours before the interface closes. Mentors are also more eager to
read applications in the beginning. Start preparing your proposal when
you first hear of Summer of Code, not right before the
deadline. Start contributing before you propose a project. If you are already a contributor to the project you are soliciting, your odds improve tremendously. (even seeking out key contributors online and befriending them in April can help) Propose a project based on past experience. Projects related to research already in progress at your school are the next best thing; it allows us to evaluate your approach, as well as giving us the assurance that you are serious about your topic and have already done background work. Have a plan. Include a full plan of action with your proposal, about one half to a full page of what you're going to do and how you think you will do it, and possibly even what you will do if your initial approach does not work. Include references. If you know anyone in open source who can vouch for your code quality and/or diligence, use them as a reference. Include academic references, as links or brief quotes, which back up your ideas. That kind of stuff impresses us. On the other hand, do NOT include 15 pages of reference materials; we won't read it. Summarize. Be realistic. SoC requires you to complete a project in 12 weeks or less. So don't be so bold that your proposal can't be finished. |
| Based on advice originally written by Josh Berkus of the PostgreSQL Project, and included here with Josh's permission. |
