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.
The older idea pages are a good reference to see how the project has evolved.
- The ideas page from 2007 is still available and a good source of information.
- The ideas page from 2008 is just an older version of the current ideas page.
You can find a possible project for Google Summer of Code in multiple locations.
- The first point of call should be the Ideas for Programmers,
- The second place to checkout is the Google Code TODO list,
- We also strongly encourage you to also come up with an idea on your own.
- Detailed description / design document
- An approximate schedule (timeline)
- Brief description of past projects (including open source) that you've participated in
- Brief resume/bio/contact information
The following links detail successful general ways to write a Summer of Code Proposal:
- HOWTO Write Project Proposals
- Inkscape's Accepted Proposals
- Internet2 Experience
- Portland State University Experience
- Monotone Experience
- Internet2 Experience
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.
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.
- Reject: Group project proposed. Google has specified that groups MAY NOT participate. Individuals only.
- Reject: Proposer is not a student. Requirement of the program.
- Read up the developer section.
- Join the mailing lists or web forums (they are connected so you don't need to join both) and ask questions
- Join the Thousand Parsec chat channel #tp, on irc.freenode.net.
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: [email protected]
- Jabber: [email protected]
- 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: [email protected]
- Jabber: [email protected]
- Responsible for: tpserver-cpp, libtpproto-cpp, Protocol Design, Ruleset development for tpserver-cpp
- Jure Repinc (JLP)
- E-mail: jlp%20AT%20holodeck1%20DOT.%20com
- Jabber: [email protected]
- Responsible for: parsek, General client development
- Brett Nash (nash)
- E-mail: nash%20AT%20nash%20DOT.%20id%20DOT.%20au
- Jabber: [email protected]
- Responsible for: AI, General client development, General ruleset development
- Krzysztof Sobolewski (jezuch)
- E-mail: jezuch%20AT%20interia%20DOT.%20pl
- Jabber: [email protected]
- Responsible for: Java code (libtpproto-java)
- Matthew Draper (matthewd)
- E-mail: [email protected]
- Jabber: [email protected]
- Responsible for: All Ruby code (such as libtpproto-rb), Improvements to protocol.xml
- Vincent Verhoeven (verhoevenv)
- E-mail: [email protected]
- Jabber: same thing
- Responsible for: daneel-ai
- Aaron Mavrinac (ezod)
- E-mail: [email protected]
- Jabber: [email protected]
- Responsible for: Single player, General Python/C++ development, Gentoo overlay
- Jotham Read (jothamd)
- Responsible for: Battleviewer, Some Artwork
- 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)
Please see the official Google timeline
Program timeline for 2010
- March 18 - List of accepted mentoring organizations published on socghop.appspot.com.
- March 29 - Student application period opens.
- April 9 - Student application deadline.
- April 26 - List of accepted student applications published on socghop.appspot.com.
- May 24 - Students begin coding for their GSoC projects; Google begins issuing initial student payments.
- July 12 - Mentors and students can begin submitting mid-term evaluations
- July 16 - Mid-term evaluation deadline; Google begins issuing mid-term student payments.
- 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
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.