• INTRODUCTION
• About This Manual
• What Is GSoC?
• Why GSoC Matters
• GETTING STARTED
• Notes for First Year Organizations
• What Makes a Good Mentor
• Defining a Project
• Selecting a Student
• COMMUNICATION
• Community Basics
• Best Practices
• Warning Signs
• Open Source Culture
• MENTORING
• Mind the Gap
• Setting Expectations
• Workflow
• Managing the Plan
• Evaluations
• WRAPPING UP
• Upstream Integration
• Building a Lifetime Contributor
• ORG ADMIN
• Making Your Ideas Page
• Selecting Projects and Mentors
• Org Application
• Managing the Mentors
• Student - Mentor Facilitation
• Other Possible Issues
• End of Year Report
• APPENDICES
• The Quick Guide
• History of GSoC
• Additional Resources
• Glossary
• Credits

Notes for First Year Organizations

Dear 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 site and the Resources section in particular, but don’t be afraid to ask questions on the appropriate mailing list, particularly the GSoC Mentor 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 about 4-5 hours a week for each student. Some weeks may be more, some weeks less. More time spent during the community bonding period and the first few weeks of the program have led to more successful and engaged students. 

* The mentor/student process is:

** OAs invite mentors to their organization.

** Talk with students about project ideas (some orgs give students a task they need to complete, that is up to you).

** Receive and review student applications.

** Request a minimum and a maximum number of requested slots for students. (OAs submit requests)

** Receive confirmation from Program Administrators with your organization's number of slots.

** Select students and mentors for each project.

* 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. Feedback is good but if you have to hand hold them now, it will be worse during the program.

* 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 3 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,

One time GSoC First Year Organizations