Google Summer of Code 2022 Administrative

From OSGeo
Jump to navigation Jump to search

GSoC2016Logo.jpg @ Osgeo-logo.png

This is the central page for OSGeo administrative information in Google Summer of Code 2022.

GSoC general information

New Modifications with GSoC 2022 (Must Read)

(citing from official GSoC 2022 announcement)

  • Starting in 2022, the program will be open to all newcomers of open source that are 18 years and older, no longer focusing solely on university students. With folks around the world changing careers, returning to the workforce, learning on their own (outside of academic programs) we see an opportunity to reach a plethora of excited individuals who want to learn more about open source and be a part of our amazing GSoC communities. Check Eligibility here.
  • GSoC Contributors will also be able to choose from multiple size projects ~175 hour (medium) and 350 hour (large). We understand not everyone can spend 30 hours a week on a coding project for 12 weeks but they would like to be a part of these communities with the help of mentors.
  • We are building increased flexibility around the timing of projects - there is an option to extend the standard 12 week coding time frame to a maximum of 22 weeks. This is to allow for folks who may realize that spreading the work over say, 16 weeks, is a more realistic goal with their current life situation. Or for contributors who have life happen in the middle of the program and they can’t work on their projects for a few weeks, but they can come back to it after a month to finish it. Hopefully this makes it easier for GSoC Contributors and mentors to be able to navigate together when obstacles occur and the GSoC Contributor can successfully complete their project.


  • Would-be mentors and students: you are invited to sign up to the OSGeo SoC mailing list right away. The list is the central communication channel for mentors, students and administrators. It is used for general GSoC announcements, specific OSGeo announcements, and for clarification about the program. As soon as you subscribe it, you are encouraged to introduce yourself and your role. We look forward to hear from you!
  • To contact OSGeo's GSoC admin team directly:

Rajat ShindeRahul Chauhan Ashish Kumar

Feel free to email us at gsoc-admin AT osgeo DOT org with questions!

  • Previous Admins (names in alphabetical order): Anne Ghisla, Carolina Arias Muñoz, Margherita Di Leo, Florin-Daniel Cioloboc, Jeff McKenna, Helmut Kudrnovsky, Werner Macho.


If you're interested in mentoring / supervising a student for one of the software participating this year under OSGeo's umbrella, please read below.

A Mentor's Responsibilities

Being a mentor can take anywhere from 2-10 hours a week of your time depending on the student (it really is in your best interest to take on the strongest students you can find). You must have the time to be responsive and an advocate for the student. No matter how cool the project is and how much your team needs the job done, if you can't commit to supporting it, experience shows that the best thing to do is not start it, i.e. even with the best of intentions don't set a student up to fail. Long story short, student projects simply can't go ahead without proper mentoring support.

Every student project will also have multiple backup mentors, and they should come from your dev community and should at minimum keep up to date with the student's weekly developments. The mentors need to appoint themselves officially. The best way is if the student is well integrated into your development team from the start, it lessens the workload on you and betters the buy-in from the rest of the community once you're ready for the final code merge.

You must be available at some time during the evaluation periods. If you will be away during these time periods please arrange with the OSGeo org admins and your backup mentor so that one of us can fill in your answers for you. These are hard cutoffs -- evaluations must be filled within these dates. There are 2 evaluation periods where mentors are required to complete an evaluation of their student from GSoC 2022. After the first 5 weeks of coding, and then at the end during submission of the project. The evaluation forms are shorter than previous years so they should take less time to complete.

Tips for mentors

This section is for collecting suggestions on best practices, from mentors to other mentors. If you have good / bad experiences in mentoring, please share here! Remember that this is a public page, respect the privacy of the people.

Good ideas

  • Test students before selection. Challenge them with small programming tasks or bug fixes. This will help them getting familiar with the dev environment well before GSoC starts, and helps mentors understand their capability. Think about coding tasks much earlier than the deadline, and connect the task to the idea in the ideas page, as tasks should reflect the skills required to develop a certain idea.
  • Time management tip: Try not to mentor more than one project per year. In any case, you can be primary mentor only for one project. Consider carefully the time that you can allocate on GSoC.
  • A former mentor reported: "In my experience, it's most effective to require an accepted pull request of developed code by end of summer and write the proposal in terms of getting there."
  • It is key getting to know the students before the project starts, in order to adapt the workload to their capabilities. In the proposal template, students are asked basic information about their background, studies and experience, but some mentors report that it can be good to get in touch via hangout or similar voip and make a sort of general interview, beside challenging them with a coding challenge.
  • If the student struggles during the GSoC, get in touch and try to understand what is wrong and try to adjust the objectives according to what is possible for the student to achieve.
  • It is often convenient to split the work into smaller tasks / clear deliverables. This way, it is easier to track the progress, both for student and mentors.
  • If the student doesn't feel oppressed with nearly impossible requests, (s)he is more likely to learn with a fresh mind and stick in the community after GSoC ends and perhaps become a mentor or somehow help out with the GSoC subsequently.
  • Talking in conferences does attract quality students to apply to GSoC
  • GSoC activities span during all year, beside the coding, it's advertising the program, attracting students, drafting ideas, cultivating mentor capacity, etc
  • ...

Bad ideas

  • If you do not always meet the deadlines, and do not always read the emails, if you feel that you don't have time, even if you really want to see a certain GSoC idea developed, it is a bad idea to consider becoming a mentor. GSoC deadlines are hard deadlines. All GSoC instructions are given via email. We do not much care of having many projects developed, but we'd rather have less, quality, well mentored projects, and students cannot be abandoned halfway.
  • If you are the kind of person always whining about the rules, please abstain becoming a mentor. GSoC has many rules, and most of them are set by Google so there is no way to change them, at least for the current GSoC. In general, GSoC rules are set for a reason, that you may or may not know, so the simplest way is either to accept them as a matter of fact or not participating at all.
  • It is a bad idea not paying attention to confidential information. Proposals ranking, comments on students work and background are exchanged via email. You need always to pay attention to the confidentiality of the content when you forward bits of emails to someone else that was not in the receivers in the first place. Furthermore, even if you know beforehand the results of selection or student evaluation, you must pay attention not to break the news to the students before they are informed by Google.
  • ...

Guides for mentors

Learn more