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