Mentors Guide

Notes for First Year Organizations

Dear 2012 First Year Organization,

Congrats! We know you're excited to participate in GSoC. We also know you're overwhelmed, so we have some advice: DON'T PANIC. The GSoC team has done this before and knows what it's doing. The program is well documented, but to get you started, here are a few tips.

General:

* This is about building the STUDENT’S experience. Getting code in your project is a nice side effect.

* Know and meet the deadlines for every part of participation: organization administration, student participation, and mentor participation. Use Google Calendars’ alert feature.

* Search the wiki, but don’t be afraid to ask questions on the appropriate mailing list. 

* Talk to experienced organizations for advice; talk to new organizations for brainstorming.

* There’s a GSoC book. Read it: http://www.booki.cc/gsoc-mentoring/

* Spread (don’t spam) the word that your organization is participating in GSoC.

Students, mentors, and slots:

* Students are not experienced project members and will take longer to write code than the core team. Plan accordingly.

* Mentors should expect to spend at least 10 hours a week for each student.

* The mentor/student process is:

** Receive mentor applications.

** Receive student applications.

** Request a number of slots for students.

** Receive confirmation of number of slots.

** Select students and mentors.

* The application process is a great initial test of the student’s dedication and skills, so don’t offer students too much help during it. 

* Use code tests and personal conversation to help select students. The student with the best proposal might not be the student who can produce the best code.

* Request 1 student slot for every 2 mentors you have. As a first year organization you will probably receive fewer than 4 students. THIS IS A GOOD THING. Use your first year to get used to the process. Expand in your second year.

Coding, community, and communication:

* Treat the student like a core contributor. Private repos or branches can prevent the student from blocking releases, but can also isolate the student from the rest of the project.

* Publish weekly or daily goals. This helps to keep scope, show progress, and keep students active.

* It’s okay to fail a student. If a student doesn’t meet agreed deadlines or doesn’t communicate, he or she should be failed.

* Make all communication public. If it didn’t happen in public, it didn’t happen.

* Show; don’t tell. Screen sharing and pair programming are often more effective than conversation.

If you have any questions just ask. We know you’ll be awesome!

Best wishes,

GSoC 2011 First Year Organizations