Summer of Code mentoring guide

1.  What it is to be a Mentor

Attributes

• Willing - A mentor should be willing to mentor. Mentoring is not a forced activity and it is not required. A mentor should not mentor half-heartedly. The Summer of Code experience is a great experience for students and part of that experience is having some help along the way. It is also a great opportunity to recruit new people into a project and this opportunity should not be squandered. Of course mentoring also offers a great opportunity for friendship.
• Informed - A mentor should know what they are signing up for; generally by reading this document. A mentor should be aware of the time requirements and any mentor who knows they cannot devote the time required should probably take a back-seat role; perhaps as a secondary or backup mentor.
• Capable - A mentor should be capable of mentoring for the given task. Knowledge of the language the student is using is important as is knowledge of the problem domain. The student will (hopefully) be asking questions about the project and their implementation (and as a mentor you should arguably be questioning their implementation as you review it.)
• Sociable - A mentor should try to foster a relationship with the student. It is important to critique the students work in a professional manner. Complaints about rudeness and abuse should be filed to the GSoC team lead and/or the Google Summer of Code staff.

Process

Being a mentor is about getting to know the student, helping the student, critiquing the student and insuring the student is making progress. These are roles generally performed by a 'Tech Lead' or 'Project Manager'. A person interested in mentoring should be prepared to do these tasks.

Helping the Student: The mentor should assist the student with common questions about the domain area, implementation and language specifics. As a mentor you should not write the code for the student; however using unrelated examples that can communicate your point to the student are a good tool.

Critiquing the student: As a mentor you should review the student's work on a regular basis and communicate daily. A student's chances of being on schedule go down dramatically if you're in contact less than once a day. Even twice a week is far worse than daily. You and the student should discuss meeting times, number of meetings, and meeting duration. It is important that you as a mentor ensure the student is staying on track and and is meeting the deadlines set forth in their application. If there are road blocks that are hindering the student's progress you should aid the student in overcoming them.

Applying to be a Mentor for GSOC 2013

Applications for mentorship are now open. You can apply on the gsoc webapp. Once you apply, you will be contacted by the program administrators (dberkholz, calchan, or antarus) to answer some questions about mentoring and why you have elected to be a Mentor. Mentor selection is currently decided at the sole descretion of the program administrators. All mentors should have sufficient involvement within the Gentoo community to support their application.

Evaluating student proposals

Please read and score all proposals so that we don't bias our scores toward ones that have more "experts" but may be less important. If you are an expert on specific topics, please be sure to review your proposals as quickly as possible so the rest of us can better judge the student's understanding of his project and his likelihood of success with it.

If you haven't participated before, note that there are both public and private comments. Public comments are seen by the student, and we expect the student to respond. Poorly communicating students will be down-ranked accordingly. Private comments are for use to discuss the student with the other mentors.

Please spend at least 5-15 minutes on each proposal for which you are not the expert (varying based on your experience level in evaluation and your reading speed).

The primary goal of our participation in GSoC is to get new developers — when you are reading proposals, consider the quality of the student your #1 priority. Of course an awesome student tends to be highly correlated with an awesome proposal, but also consider their likelihood of them sticking around once the summer ends. We would rather have a new developer than one summer's effort.

Once all mentors have had a chance to evaluate the proposals, the organization adminstrator will take their rankings into account, as well as his own expertise and the selection criteria mentioned above, in creating the final list of students.

The role of the organization administrator

The organization administrator is ultimately responsible for the success of the program. In Google's eyes, this means both passing students and new developers — this is one reason for our focus on potential developers versus a summer's work from someone who will never return. Administrators are expected to have experience with GSoC and will be knowledgeable about all aspects of the program, including the high standards expected of students and proposals, the culture of the Google Summer of Code program, and what it takes for projects to be successful. Admins should have good relationships with the Google employees running GSoC, to maximize our chances of being selected for GSoC in the future. They are Gentoo's primary contact with Google.

Administrators ensure that a good list of project ideas is submitted, write the organization application, select mentors, make final student selections, ensure mentoring is going well, resolve any conflicts, and are generally responsible for anything outside of mentoring individual students. The administrator has the final word on all aspects of the program, from mentor selection to student ranking.