Google Summer of Code

From Thousand Parsec Wiki

Jump to: navigation, search

Thousand Parsec was one of the mentoring organisations for Google Summer of Code 2007. This was a great chance for all students to work on a cool open source game project during the summer of 2007, have fun and earn some money during the process. The ideas page from 2007 is still available and a good source of information.

We're happy that in 2008 we are again participating in Google Summer of Code as one of the mentoring organizations.

Contents

Introduction

You can find a possible project for Google Summer of Code in multiple locations.

We encourage you to read up about the Getting Started Page, ask questions, and then include the following in your proposal:

  1. Detailed description / design document
  2. An approximate schedule (timeline)
  3. Brief description of past projects (including open source) that you've participated in
  4. Brief resume/bio/contact information

Writing Proposals

The following links detail successful general ways to write a Summer of Code Proposal:

Please read Google's Summer of Code Student FAQ and advice from past participants as you create your proposal. Feel free to submit multiple proposals.

Mithro has prepared some tips for writing an application. PLEASE read this before submitting an application.

Selection Criteria

The following gives some indication of some of the things we are looking for. There will probably be some subjective elements to it, but it's hoped that by trying to quantify the decision process, it'll help people understand why their application was or was not accepted.

  • Proposal is longer than a few sentences. We need some meat in the proposal in order to even consider it.
  • Proposer has contacted us prior to the submission. This demonstrates a definite interest in Thousand Parsec and proves an ability to communicate with us.
  • Proposer knows the appropriate programming language(s).
  • Proposer shows evidence of being able to create software. Our goal is to help programmers become good at Open Source, not to teach non-programmers how to program. However, we are willing to help people develop their programming skills.
  • Proposal is well written. While we don't expect perfect English, we do expect that the proposer took time to spell check, proofread it, organize it logically, and use comprehendable grammar.
  • Proposal demonstrates understanding of subject matter. We expect the proposer to do some research, ask questions, and gain some understanding of the project they're proposing. This gives us confidence that they'll be able to complete the project successfully.
  • Proposal shows creativity. We like to see someone thinking outside the box, including proposing ideas for projects we hadn't listed.
  • Proposal is the only submission for the given task. Many proposals focus on the same few tasks, so if you're the only person proposing to do a given project, that weighs in your favor.
  • Proposal shows implementation planning. If the author has broken the work out into a task list, it shows that they know what they'll be doing.
  • Proposal scope is realistic. 3 months goes fast. Proposals that are promising too much are unlikely to be completed in a timely fashion.
  • Proposal shows motivation. While it's important to describe the project in detail and show us that you have the necessary skills, do not forget to communicate your motivation, i.e. why you want to work for us on this particular project.

The following are conditions that result in automatic rejection:

  • Reject: Group project proposed. Google has specified that groups MAY NOT participate. Individuals only.
  • Reject: Proposer is not a student. Requirement of the program.

Questions

  1. Read up the developer section.
  2. Join the mailing lists or web forums (they are connected so you don't need to join both) and ask questions
  3. Join the Thousand Parsec chat channel #tp, on irc.freenode.net.

Ideas

You can find our ideas list at Ideas for Programmers page. The list is not definitive and any student is more than welcome to come up with their own idea to work on. Initiative is a skill which will rate highly when selecting projects. Feel free to come up with your own projects.

For additional ideas we encourage students to look at Thousand Parsec TODO list.

Mentors

  • Tim Ansell (mithro)
    • E-mail: mithro AT mithis DOT. com
    • Jabber: mithro@gmail.org
    • Responsible for: All Python Code (tpserver-py, tpclient-py, libtp*-py), Metaserver, Ruleset development for tpserver-py, Python client development
  • Lee Begg (llnz)
    • E-mail: llnz AT paradise DOT. net DOT. nz
    • Jabber: llnz@jabber.org
    • Responsible for: tpserver-cpp, libtpproto-cpp, Protocol Design, Ruleset development for tpserver-cpp
  • Jure Repinc (JLP)
  • Brett Nash (nash)
    • E-mail: nash AT nash DOT. id DOT. au
    • Jabber: brettnash@gmail.com
    • Responsible for: AI, General client development, General ruleset development
  • Krzysztof Sobolewski (jezuch)

There are also the following mentors, but they are smart enough not to disclose their details to the public.

  • Matthew Draper (matthewd)
  • Jotham Read (jothamd)
  • Tam Ho Wai Howell (pigeond)
    • Responsible for: Mobile/Embedded Gui, Graphics, Play testing
  • Tyler Shaub (xdotx)
    • Responsible for: TP RFTS and Ruleset development for tpserver-cpp

Deadlines and Dates

Please see the official Google timeline

Program timeline for 2008

  • March 17 - List of accepted mentoring organizations published on code.google.com.
  • March 24 - Student application period opens.
  • April 7 - Student application deadline.
  • April 21 - List of accepted student applications published on code.google.com.

Community Bonding Period: Students get to know mentors, read documentation, get up to speed to begin working on their projects.

  • May 26 - Students begin coding for their GSoC projects; Google begins issuing initial student payments.

Coding Period: Mentors give students a helping hand and guidance on their projects.

  • July 7 - Mentors and students can begin submitting mid-term evaluations
  • July 14 - Mid-term evaluation deadline; Google begins issuing mid-term student payments.

Coding Period: Mentors give students a helping hand and guidance on their projects.

  • August 11 - Suggested 'pencils down' date. Take a week to scrub code, write tests, improve documentation, etc.
  • August 18 - Firm 'pencils down' date. Mentors, students and organization administrators can being submitting final evaluations to Google
  • September 1 - Final evaluation deadline; Google begins issuing student and mentoring organization payments.

External Links

Thanks

We would like to thank the following people,

  • Creative Commons - a lot of the information in this document was adapted from their Summer of Code page.
  • Inkscape - the Inkscape project also has a large amount of stuff which was useful in creating this page.
  • Google - without Google this wouldn't even be possible.
Retrieved from "http://www.thousandparsec.net/wiki/Google_Summer_of_Code"
Personal tools