The success of a Google Summer of Code season rests on its mentors. Each student is assigned two mentors, to ensure adequate availability.

Those co-mentors can divide the work however they would like. In many cases it is convenient for one mentor to be familiar with technical aspects of Buildbot (code stuff), while the other helps the student track their progress and stay motivated (people stuff).


(note that these dates move somewhat from year to year)

  • Help to evaluate student proposals (April/May)
  • Be available to your student via email or irc or any other medium (May - Sept)
    • It's OK to be away for a few days here and there, and longer if you've arranged coverage with your co-mentor.
  • Meet with your student weekly and document the results (May-Sept)
    • This meeting is where you and the student compare notes on progress and on the student's performance, and discuss ways to improve.
    • Students sometimes fail, but when this occurs the student should have had ample chance to improve during weekly meetings
    • These meetings are *not* for discussing technical details. That should occur in a public forum. Students may need some encouragement to ask questions.
  • Communicate weekly via email with the admins regarding the student's progress
  • Perform a mid-term evaluation (July/Aug)
  • Perform a final evaluation (Sept)

Note that mentors do *not* select the project. Please be willing to mentor any student on any of the available projects.

Time Commitment

A mentor should plan to schedule out 1-2 hours per week for the purpose - mostly to meet with or be available to your student. Beyond that, you'll need some ad-hoc time for code review, answering questions, reading drafts and plans, and other kinds of problem-solving. Some weeks won't have any, and some weeks will have a heavier load. If things work out well (for example, your student creates a number of small PRs rather than one big one at the end of the summer), you can balance that load pretty well.

Technical Knowledge

You, the mentor, do not need to understand the code your student is working on. Your responsibility is to help the student use the same tools and techniques that you would to approach an unknown codebase and solve a problem: reading and interpreting code; grepping the codebase; using the code's history for context; setting up a test environment; breaking down a problem into smaller pieces; recognizing when you're stuck and need help; and asking for help with focused questions in the right environments.

Your knowledge of Buildbot in general (either as a user or as a contributor) will be important, as well: your student most likely has never used Buildbot before, so the requirements of the project are probably quite baffling.

You are not expected to do code review for your student's work. That will be handled on pull requests as for any other contribution.


  • Let the admins know about your intentions.
    • If you would like to co-mentor with a particular person, be sure the admins are aware of that.
  • Apply at ASAP. The application process carries no obligation, but allows you to see student proposals.
Last modified 3 years ago Last modified on Feb 17, 2016, 2:55:55 AM