Google Summer of Code

From Thousand Parsec Wiki
Revision as of 22:48, 22 March 2010 by Lee Begg (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Thousand Parsec was a mentoring organisations for the Google Summer of code in 2007, 2008 and in 2009. This was a great chance for students to work on a cool open source game project during their summer, have fun and earn some money during the process. We have been selected to participate again in 2010.


Historic Ideas Pages

The older idea pages are a good reference to see how the project has evolved.


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

  • We also strongly encourage you to also come up with an idea on your own.

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.

Feel free to write your proposal on the wiki. Please link it from the Proposals2010 page.

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.


  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


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 the Thousand Parsec TODO list.


  • Tim Ansell (mithro)
    • E-mail: mithro AT mithis DOT. com
    • Jabber:
    • 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:
    • 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:
    • Responsible for: AI, General client development, General ruleset development
  • Krzysztof Sobolewski (jezuch)
  • Matthew Draper (matthewd)
  • Vincent Verhoeven (verhoevenv)
  • Aaron Mavrinac (ezod)

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

  • 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
  • Eugene Tan (jmtan)
    • Responsible for: TP 3D client development (tpclient-pyogre)

Deadlines and Dates

Please see the official Google timeline

Program timeline for 2010

  • March 18 - List of accepted mentoring organizations published on
  • March 29 - Student application period opens.
  • April 9 - Student application deadline.
  • April 26 - List of accepted student applications published on

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

  • May 24 - 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 12 - Mentors and students can begin submitting mid-term evaluations
  • July 16 - 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 9 - Suggested 'pencils down' date. Take a week to scrub code, write tests, improve documentation, etc.
  • August 16 - Firm 'pencils down' date. Mentors, students and organization administrators can being submitting final evaluations to Google
  • August 20 - Final evaluation deadline; Google begins issuing student and mentoring organization payments.
  • August 30 - After this date, students submit code samples to Google

External Links


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.
Personal tools