Changes

Jump to navigation Jump to search

Summer of Code/Project Rules

89 bytes added, 15:50, 8 April 2011
Adapt a bit more to the fact we are using git now.
* ...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 either [https://github.com/scummvm/scummvm/pulls via a pull request from your own git repo fork] or [http://sourceforge.net/tracker/?group_id=37116&atid=418822 using our patch tracker]. Fix some known bug, extends functionality in some way, add a new unit test, 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 '''(Git master)''', 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 [http://panospace.wordpress.com/2009/03/25/a-patch-the-first-milestone/ blog post by Yuval Levy] from the [http://hugin.sourceforge.net/ hugin project], which explains the rationale behind this requirement.''
561

edits

Navigation menu