GSoC Guide for Mentors #
These are Open Science Labs' (OSL) general recommendations for projects and sub-organizations participating in Google Summer of Code (GSoC) under the OSL umbrella. Organization admins and maintainers can use, adapt, or incorporate these recommendations partially or completely into their own project guidelines. Contributors: also read the guidelines of the project you are contributing to. Official GSoC rules and applicable codes of conduct still apply.
Prepare the Project and Welcome Candidates #
Publish the preferred community app or communication channel, contact details, and expected response times alongside the project idea. Explain the project's mission, intended users, main workflows, and development setup. State which ideas are planned for the upcoming GSoC edition and update candidates when plans change.
Provide a manageable starting workflow and examples of helpful contributions, including documentation, tests, and bug fixes. Encourage candidates to spend several days using the software before rushing into a pull request. For a tool or library, suggest different use cases and realistic tasks so candidates can understand both its strengths and its limitations.
Use a Project Experience Report as the First Contribution #
Ask candidates to write a blog post or newcomer experience report from a user's perspective. Use it as an initial selection criterion and announce the expected effort, deadline, submission channel, and assessment criteria in advance.
Assess what the candidate tried, how clearly they explain the software, what they learned, and the usefulness of their observations. Value reproducible examples and constructive suggestions. Accept a Markdown document or draft shared with the team without requiring a personal blog or a pull request. If setup fails, review the steps attempted and the blocker, and help the candidate move forward.
Keep the task manageable and give candidates time to explore. Do not require a long history of contributions; use the activity to help newcomers develop and demonstrate understanding.
Publish a Project Selection Checklist #
Align project criteria with the organization's selection framework. For example:
- [ ] The applicant meets the current official GSoC eligibility requirements.
- [ ] The project experience report meets the published criteria.
- [ ] The proposal explains the project's goals and includes the requested sections.
- [ ] The candidate follows the published AI-use and disclosure policy.
- [ ] The candidate shows meaningful engagement and responds within agreed windows.
- [ ] Availability and proposed scope are realistic for the project.
Include a small, explicit, project-relevant instruction to check that candidates read the guidance. Request a "Newcomer insight" proposal section with one observation from trying the software. Include it in the instructions and checklist, and explain how omissions are handled. Use the response to discuss the candidate's experience and understanding.
Make the AI Policy Specific #
Explain permitted and prohibited uses separately for proposals, experience reports, code, tests, and documentation. State whether editing, translation, brainstorming, or code generation is allowed; what tools or data restrictions apply; and how assistance must be disclosed. Link the policy from the project idea, proposal instructions, and contribution guide.
Assess understanding through the work and discussion. Describe how suspected violations will be reviewed and let candidates explain their work. Writing style alone is not evidence of AI use.
Review Proposals and Agree on Expectations #
Assess proposals using the published checklist and assessment rubric. Provide clear feedback and discuss alternatives when another project is a better fit. Look for thoughtful questions, responses to feedback, useful observations from using the software, and follow-through on agreed tasks.
Share a contributor checklist before selection covering deliverables, reporting frequency, response windows, check-ins, AI policy, review participation, and evaluation criteria. State your own availability, review turnaround, and backup contact. Explain what happens when expectations are repeatedly unmet.
Confirm the working agreement during community bonding, including time zones, planned absences, and any adjustments. Keep a shared record of changes.
Support Progress and Address Problems Early #
Set clear weekly objectives, hold regular check-ins, and review daily status reports on agreed working days. Respond to requests for help and give actionable feedback. During selection, announce any reporting exercise in advance and limit it to a short, defined activity.
If progress or engagement falls short, discuss specific examples privately, identify blockers and gaps in mentoring support, and agree on next steps and a review date. Distinguish persistent failure to follow through from an agreed absence or a technical obstacle raised promptly.
Decline candidates who do not meet published selection criteria. During the program, give an honest failing evaluation when agreed expectations remain unmet; passing someone solely to avoid a difficult conversation helps neither the contributor nor the project. Coordinate with organization admins, document the basis for the decision, and follow the current GSoC evaluation process. Communicate concerns early and provide feedback before the evaluation.
For official mentoring guidance, see Setting Expectations, Selecting a Contributor, and Evaluations.
See the GSoC guide overview for all roles.