Mentors Guide

The Quick Guide

The process begins with proposing projects and selecting students over about a four week period. This is followed by six to eight weeks of community bonding. The coding phase runs for twelve weeks. A final one-week "pencils-down" phase wraps up the project.

  • During the student selection phase the mentor will be responsible for helping find a fit between project, student proposal and mentor. This will include defining the proposal process, assisting in the evaluation of proposals, querying the students, providing them feedback about their proposals and ultimately finding a student proposal to mentor.

  • During the community bonding phase, the mentor and student will further define the student's project and prepare for development. An important part of this phase, as the name implies, is to get the student connected with both the mentoring organization and the larger open source community.

  • During the coding phase the student will be implementing the project. The mentor will be providing advice not just on the technical aspects of development, but on issues related to the interaction of the student's work with the organization. At midterm the mentor will evaluate the student's progress to determine whether the student will continue with the project and be issued a payment by Google.

  • During the final phase the mentor will help the student submit a code sample to Google. The mentor will also perform an evaluation of the student's work to determine whether Google should issue a final payment.

Quick Tips on Effective Mentoring

The tips in this section are no substitute for reading this book.  However, they may serve as an introduction to the material herein.

Project Definition: An ideas page is the starting point for project definition.  You should include projects that you are interested in mentoring for the summer and that appeal to students and to your organization.

Selecting Students: Students come with many motivations; try to understand why your applicant is applying. It is better to give up a student slot than to select a student whose performance is likely to be poor.

Communication: Engage with your student as early as possible. Integrate the student into your community and its communication channels. Make sure that communication with your student is frequent and regular.

Collaboration: Start by working with your student to set solid expectations and goals for the project. Develop a detailed project plan, with deadlines and milestones. Be prepared for slippage, and be willing to revise the plan as necessary, especially at midterm. Student learning is a primary goal of GSoC, so try to provide a learning experience.

Evaluation: Keep your student evaluations objective; base them on your project plan.  Keep in mind that it is better to fail a student earlier rather than later—data shows that students doing poorly at midterm rarely complete a GSoC project.  Make sure your students hear your evaluations: deliver praise in public, and criticism in private.

If you follow the above advice, and the rest of the advice given in this book, you have a good chance to have a successful experience. Positive outcomes might include recruiting a permanent developer to your community, developing a lifelong relationship with your student, and helping the open source community grow and thrive.