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.
• ... get in touch with us and our community. In particular, visit our IRC channel #scummvm on irc.freenode.net, and/or email the technical contacts listed on the OpenTasks page for each task that sounds appealing to you.
  • Your best chance to find out whether ScummVM is right for you, and whether you are right for ScummVM, is to talk to us. We'll be happy to answer your questions, and help you decide whether you like to work with us. Your chances of being accepted later on will also be much higher if we already know you a bit. And finally, regular attendance of our IRC channel is almost mandatory if you want to work with us anyway ;-)

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 (SVN trunk), 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 this. In fact, finding out whether you communicate well with us and are willing to ask questions and learn is part of the test. There is a nice blog post by Yuval Levy from the hugin project, which explains the rational behind this requirement.

During GSoC...

• ... we require you to communicate with your mentor every second day. Failing to do so for more than three days without arrangement will cause you to be dropped from the program.
  • Consider that GSoC is a full time obligation. If you don't show up on a regular job for three days in a row, without any prior notice or reporting in as ill, you also run a high risk of being fired. Now, this is not exactly a regular day job and you don't have to come into an office every day. But communication is absolutely essential 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. In particular, if you feel you are behind your schedule or otherwise in troubles, talk to us as soon as possible. Do not hide from your mentor -- he is here to help you at all times. Finally, this obligation doesn't have to be a burden, but rather should be a fun opportunity to chat with a nice fellow coder about interesting topics.
• ... we ask you to keep a weblog (BLOG) with posts on a weekly or more frequent basis detailing your progress and experiences with your 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 spend hours making the code compile is a very thankless task ;) when that time could be better spent on review.
• ... we expect you to commit early, commit often.
  • 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.