GSoC Guide for Contributor Candidates #

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.

Start in the Community's Preferred Channel #

Find the project's preferred community app or channel and use it for your first contact. Introduce yourself, explain your interests, and ask:

• Does the organization intend to participate in the upcoming GSoC edition?
• Which of its projects or project ideas are planned to participate?
• Where can I find the relevant documentation and discuss getting started?

Ask about the team's plans for the upcoming GSoC edition rather than assuming participation based on a previous year. Choose a project that aligns with your interests, skills, and learning goals. Allow time for replies and keep technical questions in the community channel so others can learn and help.

Spend Time Using the Software #

Use the software as a user before rushing to change its code. Spend several days exploring it, follow the documentation, and try it on a real task or a need you understand. For a tool or library, test different contexts and use cases rather than stopping after one quick-start example.

Discuss your experience with colleagues, other users, and the community. Ask questions, compare approaches, and understand why existing workflows work as they do. Keep notes about examples, strengths, confusing steps, and limitations. Hands-on experience helps you identify useful improvements and explain why they matter to users.

Write About Your Experience as a User #

Before opening a pull request, write a blog post or newcomer experience report covering:

• The project's mission, main objectives, and intended users.
• What you used it for, why you chose those tasks, and the contexts you explored.
• How to install or access it, with reproducible examples for other newcomers.
• What works well and which features or workflows you found useful.
• What was confusing, what could work better, and any setup or documentation obstacles.
• Constructive suggestions, questions discussed with others, and what you learned.

Take time to develop observations from actual use. Write an honest account with specific examples. Follow the announced submission process; a draft or Markdown document shared with the team is enough when public publication is not requested. If setup fails, document what you tried and where you became blocked.

Then agree on a small follow-up contribution with a mentor, such as improving onboarding documentation, adding a test, or fixing a bug. Focus on useful work and responding to feedback rather than maximizing the number of pull requests.

Prepare Your Proposal #

Develop a detailed proposal with mentor feedback that explains:

• Impact: How the work advances the project's goals and helps its users.
• Plan: Specific tasks, deliverables, milestones, timeline, and risks.
• Availability: Time commitments and planned absences.
• Newcomer Insight: An observation from using the software and a suggested improvement.

Use clear, concise language. Follow the published AI-use policy, disclose assistance as required, and verify everything you submit. Write a proposal that reflects your own understanding and be prepared to explain your choices.

Review the official rules, the selection checklist, and the assessment rubric before applying. Use the proposal template.

Review Process #

Notify mentors in the designated channel when your proposal is ready for review. Respond to feedback, ask clarifying questions, and allow time for replies. Show engagement through thoughtful discussion, useful progress updates, support for peers, and follow-through on agreed tasks. The recommended internal rubric gives community engagement 50% of the assessment and technical understanding and planning the other 50%.

After Selection: Work with Your Mentor #

Agree on weekly objectives, check-in times, reporting channels, response windows, and planned absences. Send a brief daily status report on agreed working days using a shared thread or project log. Include:

• Progress: What I worked on or learned, with links where relevant.
• Next: What I plan to do next.
• Blockers: What is preventing progress and what help I need.

Report blockers even when no code was completed, and give early notice of changes in availability. Ask for help, respond to reviews, and use feedback to improve your work. Follow the Coding Tips for readable code, focused pull requests, testing, and documentation.

Consult the GSoC Student Guide and Google's advice for contributors for further application guidance.

See the GSoC guide overview for all roles.