GSoC Guide for Organization Admins #
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.
Coordinate Participation and Mentor Capacity #
Confirm which affiliated projects intend to participate in the upcoming GSoC edition and which project ideas they plan to submit. Distinguish planned participation from confirmed participation when communicating with candidates. Keep project ideas, contacts, and participation updates easy to find.
Confirm mentor availability and backup coverage before offering project ideas. Balance contributor allocations across projects and mentors, and keep the scope within the mentoring capacity available. Do not promise candidates a place before selection and slot allocation are complete.
Publish the organization contact channel, selection timeline, and escalation route for candidates and mentors. Use OSL's coordination channels for matters across projects and each project's preferred community channel for its work.
Publish the Selection Framework #
Publish common selection criteria, the assessment rubric, and evaluation expectations before the selection period begins. Coordinate with mentors to make project-specific criteria equally clear. Separate minimum requirements that exclude an application from scored preferences used to compare suitable candidates.
For each minimum requirement, state the evidence, deadline, whether correction or clarification is possible, and how unmet criteria affect selection. Use the same published criteria consistently, record selection reasons, and account for agreed accessibility or scheduling accommodations. Meeting the checklist does not guarantee a slot. Review the current official GSoC rules when defining eligibility and selection procedures.
Give Community Engagement Explicit Weight #
Assign 50% of the internal assessment to community engagement. Use the remaining 50% to assess technical understanding and planning during selection, and agreed deliverables and code quality during the program. Publish the rubric, evidence, and minimum thresholds for both areas. For example:
| Area | Weight | Evidence to consider |
|---|---|---|
| Communication and reliability | 20% | Useful updates, timely replies within agreed windows, and early notice of blockers or absences. |
| Collaboration and response to feedback | 20% | Constructive discussion, follow-through on review, and support for peers where opportunities arise. |
| Learning and sharing project understanding | 10% | User experience reports, documentation, or explanations that help others learn. |
| Technical understanding and project work | 50% | A feasible proposal during selection; tested, documented progress against agreed goals during the program. |
Assess observable behavior rather than personality, English fluency, message volume, or constant availability. Give newcomers a reasonable opportunity to demonstrate each criterion. A strong engagement score does not remove the need to meet agreed technical goals. Use this rubric for internal assessment alongside the official GSoC evaluation requirements.
Support Consistent Decisions and Resolve Problems #
Check that mentors publish their expectations before selection, provide timely feedback, and have enough capacity to support their contributors. Arrange backup support when a mentor is unavailable.
Review concerns and evaluation decisions with mentors, including evidence of missed expectations, support provided, and feedback shared with the contributor. Address gaps in mentoring support as well as contributor engagement. Follow the current GSoC evaluation process and communicate decisions clearly.
See the GSoC guide overview for all roles.