Summer of Code/Project Rules

Here you will find several important rules which you have to agree to follow in order to be eligible to apply as a student for the ScummVM project.

These rules exist to make the program as rewarding and problem free for all concerned and are designed based on several years experience to help you get the most out of GSoC. Really, these are not meant to annoy you, rather we believe that by following them you will benefit far beyond just making us happy ;-).

Before you apply...

• ... take into account that Google Summer of Code is a full time job. If you consider getting an additional part time job, have extensive exams or an extended vacation during the program, you likely should not apply. If you do anyway, please make sure to explicitly list your other commitments in your application.
  • Experience in previous years' GSoC has shown us that students with extensive extra commitments during the GSoC coding phase tend to really struggle to meet their goals. GSoC becomes a burden instead of being fun.

Before you are accepted...

• ...prepare a comprehensive and detailed plan for all 12 weeks of your project. Include risk mitigation (you might fall ill, a phase in your project be more complicated than anticipated, etc.) and any existing commitments such as exams, vacations etc.
  • This plan will help you and us to decide at any time during the project how well you are progressing. It forces you to think about what you need to do beforehand, and provides a guideline for you while GSoC is progressing.
• ...you are expected to submit a patch against our Subversion source code using our patch tracker. Fix a typo in the README, or some known bug, extends functionality in some way, or provide a start for the work you are applying for.
  • This is the basic entry bar to ensure that applicants are familiar enough with the code and concepts in ScummVM to submit a patch. I.e., whether you manage to checkout the source, compile it, make a change, and then use our patch tracker to submit it. Don't worry, though: It does not have to be anything complex, and you are highly welcome and even expected to ask us for help and guidance with every step. In fact, finding out whether you communicate well with us and are willing to ask questions and learn is part of the test. Don't be shy, we are a friendly bunch :-).

During GSoC...

• ... we require you to communicate with your mentor every second day. If you fail to do that for longer than three days without arrangement, you will fail the program.
  • Communication is key to a successful GSoC project and experience has shown that students that do not check in with their mentors (and the wider community) tend to struggle and produce weaker outputs.
• ... we ask you to keep a weblog (BLOG) with posts on a weekly or more frequent basis detailing their progress and experiences with their project/GSoC.
  • This provides a valuable avenue for feedback and helps involvement of the wider community. It also helps you to sort your thoughts and determine your own progress. Note that the blogs will be aggregated onto ScummVM's Planet site so language and tone should be set accordingly.
• ... your code must comply to our Code Formatting Conventions.
  • The formatting conventions are one of the main ways we keep consistency with such a large codebase. We want students to work towards their code being incorporated into mainline ScummVM and this is a prerequisite.
• ... you should at the very least verify that your code is compilable before you commit it.
  • Checked in code does not have to be feature complete or anything like that but it should at least compile at all times. Mentors regularly review students' code and having to speed hours making the code compile is a very thankless task ;) when that time could be better spent on review.
• ... we expect you to commit often, commit early.
  • We judge students' code based on what is checked in and take the view that 'if it's not checked in it does not exist' for the purposes of GSoC reviews. Don't be shy about this. You may feel your code is not 'good enough', but the best way to learn whether it actually is good or not, and also to get valuable hints on how to improve it, is to show it to us. Trust us, we will give you constructive feedback and won't bash you for what you produce.