Mentors

Interested in volunteering with the Python Software Foundation?

The biggest job is mentoring new contributors: Mentoring a GSoC contributor as a primary mentor can be a pretty big time commitment (see "What does it take to be a mentor?" for more information) but it's a very rewarding chance to give a GSoC contributor an open source apprenticeship. We mentor in teams, so if all you can handle is a few code reviews or taking over for a week while someone's on vacation, you can team up with someone with more time.

The easiest way to become a mentor is to be part of one of the sub-orgs that plan to be involved, so get in touch with them directly if you want to help. If you're part of a group that would like to participate as a sub-org, please read the section for sub-orgs below.

If you're not already part of a group that wants to participate, we can try to match you with one, but be aware that to do the best job of mentoring you're going to need to know the open source project pretty well yourself. If you're not already a developer, you should be prepared to become an active community member.

But we often need other volunteers! We're also looking for friendly community members to help with other tasks! We'd love to have more people available on IRC/Mailing lists to answer GSoC contributor and mentor questions in various time zones. We are particularly looking for volunteers who can read and comment on contributor posts, remind contributors if they haven't posted, and promote the work our GSoC contributors do to the larger Python community. Or maybe you have another skillset you'd like to contribute? (Proofreading? Recruiting diverse contributor applicants?) If you want to help, we can try to find a way to make that happen.

If you'd like to volunteer, get in touch with a sub-org admin or email the Python org admins at gsoc-admins(at)python(dot)org

What does it take to be a mentor?

Time commitment

We expect around a 0-10hr/week commitment, which sounds scary, but it's not actually that variable. You usually spend up to lots of time for the first few weeks, where you're fleshing out your ideas page, discussing projects with many contributors, and selecting contributors from their proposals. After contributors are selected and settled in, it becomes more like a 1hr commitment per week for a weekly meeting, and maybe a few more hours here and there for code review or questions. (That depends on your GSoC contributor: experienced contributors may need very little supervision, inexperienced contributors may need more. It also depends on you: You and your co-mentor(s) select the person and project you mentor, so you can choose according to the time commitment you have. Some mentors even do pair programming with their GSoC contributors!)

I recommend at least one mentor has a weekly 1hr meeting with the GSoC contributor so they get to know each other, keep everyone on track, and give a chance to talk about other stuff. Lots of contributors have questions about jobs, courses, architecture, open source, etc. and it's nice for contributors to have someone to talk to especially since many of them will not have worked remotely on their own for any length of time before. Some weeks this meeting may be the only mentoring time needed.

Work Together

We want at least two mentors per project, so hopefully no one ever gets overwhelmed and feels like they're always on call (Google does ask that we try to answer questions within 48h so contributors can't get stuck for too long), and no one mentor has to know all the answers.

Knowledge required

Our most successful mentors are those who are already developers or community members of their open source project. If you're joining a new project for GSoC, expect to take time to learn the ropes yourself so you can help GSoC contributors.

Mentors don't have to be the Best At Everything. A lot of what mentors do is keep contributors on track and keep them from getting stuck for too long. Sometimes that means just knowing who to ask or where to look rather than knowing the answer yourself.

In an ideal world, at least one mentor can answer at least basic architectural questions and knows how to get code accepted upstream. Not every mentor has to be a coder: experienced users can help contributors understand why features make sense (or dont!), system administrators can help contributors understand how deployment works in practice, experts in areas like accessibility, usability, and security could help guide contributors in their areas of expertise.

Evaluating GSoC contributors

Mentors do have to do multiple evaluations on each GSoC contributor, two mid-terms and one at the end. Usually the mentors discuss and then the "primary" mentor fills in the evaluation with input from all mentors. There's a few questions about how the GSoC contributor is doing and then a pass/fail that determines if the GSoC contributor gets paid and continues in the program.

Sub Orgs

Looking for the list of currently accepted sub-orgs? It's the project ideas list.

To participate under the Python umbrella, a sub-org must do the following:

  1. Be a Python-based open source project that meets Google's requirements for GSoC.
  2. Email gsoc-admins@python.org for the registration application
  3. Have one sub-org admin and at least two mentors who are willing to commit to the full GSoC period. (More is awesome!) Thats a minimum of 3 people total, although your sub-org admin is allowed to also be a mentor or backup mentor.
    • If you want to connect with more potential volunteers, email gsoc-admins@python.org to see if we can match you with volunteers who don't have a project.
  4. Accept the Python Community Code of Conduct for the duration of the program.
  5. Send an email indicating interest to gsoc-admins(at)python(dot)org before the Python deadline (exceptions can be made if you get an amazing GSoC contributor applicant later and want to sign up just for them).
  6. Have a good ideas page. We have a template below. Getting a really great page sometimes takes a few rounds of revisions; We will work with you to make sure your page is ready!
  7. Be able to handle meeting deadlines and following both Google and Python's rules. We try to send important reminders for big deadlines, but we only have limited volunteer time for nagging and cajoling. Groups that cause repeated problems may be asked to take time off to limit core volunteer burnout.
  8. Disclose all potential conflicts of interest to the Python admins BEFORE accepting a GSoC contributor. If you are unsure, ask. If a conflict is found after the fact the GSoC contributor and sub-org may be dropped from the program. (Examples: GSoC contributor is involved in your research group, GSoC contributor is your child, GSoC contributor owes you money, etc.)
  9. Give access to any private communication channels to the PSF admins for the duration of GSoC that are used for the project, ie slack, private git repo, discord etc. This is mostly so we can reach you where you're already looking for gsoc-related messages, but could also be used if a GSoC contributor has a dispute with a mentor and asks for our help.

We can't promise to take everyone who meets those criteria, but we do try to take any group that we feel will give the GSoC contributors a great experience. Terri has final say in which projects participate under the Python umbrella, but please send any queries to all the admins at gsoc-admins(at)python(dot)org to make sure we're all on the same page.

Python projects are welcome and encouraged to apply as separate mentoring organizations directly with Google. We're happy to help you in any way we can and we don't mind being your backup plan. We're also happy to help advertise python based organizations not under our umbrella: we want GSoC contributors to find projects that best suit them!

Please note: The funds Google gives Python as mentor stipends are given to the PSF grants program rather than dispensed per sub-org.

Python Sub-org Ideas Template

There are not very many strict requirements for Google Summer of Code Ideas pages, but there are some things that GSoC contributors often ask us for. This page is intended as a starting template for organizations so you don't forget those things.

Warning: In 2014, many orgs got rejected because their ideas pages were offline when Google checked. Make sure your ideas page is hosted somewhere that Google's Open Source Programs Office will be able to access when they check!

About MyOrg

Tell the prospective contributors a bit about your organization. Here's some questions you might want to answer:

  • What software are you creating?
  • Why is it interesting?
  • Who uses it?
  • What languages is it written in?
  • How is it going to change the world?

Contacting MyOrg

  • IRC channel:
  • Mailing list(s):
  • List contact methods you actually use and will have mentors monitoring!

Include any special instructions/info about communicating: e.g. what time zones are your mentors in? do you prefer it if GSoC contributors introduce themselves first or just dive in? are there any common mistakes contributors make when making a first impression?

Getting Started

Links to setup instructions go here. Some suggested things to answer:

  • Where is the link to a setup guide for new developers?
  • Are there any unusual libraries/applications that need to be installed first?
  • What type of source control do you use? (include links to help and setup guides!)
  • What's the process for submitting your first bug fix?
  • Where should new contributors look to find easy bugs to try out?

Writing your GSoC application

Links to advice about applications and the application template goes here.

Project Ideas

You should usually have a couple of project ideas, ranging in difficulty from beginner to expert. Please do try to have at least one, preferably several beginner tasks: GSoC gets a lot of new contributors with minimal open source experience who feel very discouraged (and sometimes even complain to Google) if orgs don't any have projects at their level.

1. Project name

  • Project description: Make sure you have a high-level description that any new GSoC contributor can understand, as well as deeper details
  • Skills: programming languages? specific domain knowledge?
  • Difficulty level: Easy/Intermediate/Hard classification (contributors ask for this info frequently to help them narrow down their choices. Difficulty levels are something Google wants to see, so they aren't optional; make your best guess.)
  • Related Readings/Links: was there a mailing list discussion about this topic? standards you want new contributors to read first? bugs/feature requests?
  • Potential mentors: A list of mentors likely to be involved with this project, so GSoC contributors know who to look for on IRC/mailing lists if they have questions. (If you've had trouble with GSoC contributors overwhelming specific mentors, feel free to re-iterate here if GSoC contributors should contact the mailing list to reach all mentors.)
  • Project Length: Medium size projects should take about 175 hours to complete while large projects should take about 350 hours to complete, you should put if the project idea would be a medium or a large project.

2. Project name

As above. etc. Unless there's a compelling reason to sort in some other order, ideas should be ordered approximately from easiest to hardest.

If you're open to other project ideas from contributors, say so and make sure there's a clear path for contributors to discuss ideas with mentors before submitting an application. Otherwise, we've found that you'll get a lot of project ideas that aren't suitable for GSoC: too small, too large, bad fit for the project, no mentors interested in taking them on, etc. You may have an open discussion thread in your bug tracker/forums, a chat channel or mailing list, or contact info for a mentor who's open to discussing new ideas in private.