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