Changes between Version 2 and Version 3 of SummerOfCodeMentorGuidelines


Ignore:
Timestamp:
May 12, 2019, 8:21:45 PM (5 years ago)
Author:
neverpanic (Clemens Lang)
Comment:

We don't only expect male students, and we're using Git now where "trunk" is no longer a thing

Legend:

Unmodified
Added
Removed
Modified
  • SummerOfCodeMentorGuidelines

    v2 v3  
    55You as a mentor are there to help your student, review your student's work and insuring that your student makes progess.
    66
    7 Helping means that you should answer general questions in the problem domain, but do not write the code for him as that is his job and what he gets paid for. Instead give hints and smaller (unrelated) examples how to solve the problem they might encounter.
     7Helping 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.
    88
    99Reviewing 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.
     
    1313== Other Remarks ==
    1414
    15 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 trunk already. Students might promise to continue working on their project after the summer, but from our experience this statement seldom holds true.
     15In 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.