208
edits
Difference between revisions of "Summer of Code/Project Rules"
Reword rules a little.
(mention that patches could also extend existing functionality) |
(Reword rules a little.) |
||
| Line 1: | Line 1: | ||
Here you will find several important rules which you have to | 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. | ||
* Google Summer of Code is a '''full time job'''. If you consider getting an additional part time job | These rules exist to make the program as rewarding and problem free for all concerned and are designed to help you get the most out of GSoC. | ||
* We | |||
* We require each student to communicate with their mentor every second day. If you fail to do that for longer than 3 days, you will fail the program. | * 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 please do not apply. | ||
* Students are expected to submit a patch which fixes some known bug, extends functionality in some way, or is a start of their work | ** ''Experience in previous years GSoC has shown us that students with extensive extra fixed commitments during the GSoC coding phase tend to really struggle to meet there goals.'' | ||
* | * We require a comprehensive and detailed plan for all 12 weeks of your project. Include risk mitigation and any existing commitments. | ||
** ''This plan provides one of the key markers we will use to judge the your progress with your project.'' | |||
* We require each student to communicate with their mentor every second day. If you fail to do that for longer than 3 days without arangment, 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 there mentors (and the wider community) tend to struggle and produce weaker outputs.'' | |||
* Students are expected to submit a patch with or before there application which fixes some known bug, extends functionality in some way, or is a start of their work that they 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. It does not have to be a complex patch and we will willingly provide help and guidance.'' | |||
* We ask students to keep a weblog (BLOG) with posts on a weekly or more frequent basis detailing there progress and experiences with there project/GSoC. | |||
** ''This provides a valuable avenue for feedback and helps involvement of the wider community. Note that the blogs will be aggregated onto ScummVM's Planet site so language and tone should be set accordingly.'' | |||
* Stick to our [[Code Formatting Conventions]]. | * Stick to our [[Code Formatting Conventions]]. | ||
* The code has to be always at least ''compilable''. | ** ''The formatting conventions are one of the main ways we keep consistency with such a large codebase. We want students to work towards there code being incorporated into mainline ScummVM and this is a prerequisite.'' | ||
* Checked in code has to be always at least ''compilable''. | |||
** ''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.'' | |||
* Commit often, commit early. | * Commit often, commit early. | ||
** ''We judge students code based on what is checked in and take the view that 'if its not checked in it does not exist' for the purposes of GSoC reviews.'' | |||