Summer of Code Guidelines for Mentors

Responsibilities

You as a mentor are there to help your student, review your student's work and insuring that your student makes progess.

Helping means that you should answer general questions in the problem domain, but do not write the code for them as that is their job and what they gets paid for. Instead give hints and smaller (unrelated) examples how to solve the problem they might encounter.

Reviewing means that you should know what your student is working on at the moment. Schedule regular meetings or reports (via E-Mail, IM/IRC, Skype) with them to discuss progress. In the past once a week has been a good rate of meetings, but you should figure out with your student which interval and medium works best.

Ensuring the progress means that you are responsible to help your student overcoming blockers by giving them the aid they need. If you don't know how to solve it either, give the problem to other mentors or ask the general development mailing list. If you student does not meet deadlines, it's your responsibility to let them fail at evaluation. Failing a student should be discussed with other mentors before so it cannot be considered as an unfair or biased decision.

Other Remarks

In 2013, we changed our policy for submitting the final code in contrast to the previous years. We required that all code written during the summer must be merged into our trunk development branch by the end of the program. This ensures that we will be able to definitely use the implemented feature right away. From the past years, branches are still lying around unmerged, because after the work was finished, nobody got around to make the final touches and merge it back. There is a much higher chance of getting things fixed by other developers as well if it is on master already. Students might promise to continue working on their project after the summer, but from our experience this statement seldom holds true.