Summer of Code mentoring guide
What it is to be a Mentor
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.
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
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.