Differences between revisions 1 and 2
Revision 1 as of 2006-05-24 17:28:55
Size: 1431
Comment:
Revision 2 as of 2006-05-26 20:29:07
Size: 1822
Editor: JimJJewett
Comment: emphasize the need for deliverables and timeline
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Line 13: Line 12:
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.) 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.

Tips on writing your proposal

Be detailed. Don't say "I want to improve Python'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?

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?

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. In 2005, some interesting projects went unfunded because there was no one in the pool of mentors who felt capable of handling them.

SummerOfCode/Proposals (last edited 2008-11-15 13:59:43 by localhost)

Unable to edit the page? See the FrontPage for instructions.