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 rewarding and problem free for all concerned and are designed based on several years of 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 GSoC Ideas 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 ;-)

• Get familiar with the code base. Clone our GitHub repository, compile the source code. Play with it. See Developer_Central for how to get started.

You will need to know a bit about the project to work on your application. Also as part of the application you will need to provide a pull request with some code change to demonstrate that you can work with the code base (see Before you are accepted... below).

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.

• Submit a code patch via pull request which follows our Commit Guidelines. Fix some known bug, extend functionality in some way, add a new unit test, or provide a start for the work you are applying for. Remember, this is an activity for the Summer of Code program, so while documentation improvements are always welcome, they don’t meet this requirement.

This is the basic entry bar to ensure that applicants are familiar enough with the code and concepts in ScummVM to submit a change. I.e., whether you manage to checkout the source (Git master), compile it, make a change, commit it, and then push it to github. 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. Don't panic! 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 rationale 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 -- they are 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 and to push your commits to GitHub often (ideally every day, or even multiple times a day).

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.

• Be present on our IRC channel while you work. This is not a strict rules but a strong suggestion.

The IRC channel is where you will usually want to ask questions about your task, and might get help from other developers. Our code base is quite big and we know it takes time to get familiar with it. If you are not sure what the best way to do something is, please ask. It is good to take some time to think about it yourself before asking, but don't wait too long if you get stuck. There is no stupid question. Also the IRC channel is the best place to meet our community and discuss old point&click adventure games or related topics!