Mentors

Interested in volunteering with the Python Software Foundation?

The biggest job is mentoring students: Mentoring a student 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 student 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 student and mentor questions in various time zones. We are particularly looking for volunteers who can read and comment on student blogs, remind students if they haven't posted, and promote the work our students do to the larger Python community. Or maybe you have another skillset you'd like to contribute? (Proofreading? Recruiting diverse student 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 students, and selecting students from their proposals. After students 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 student: experienced students may need very little supervision, inexperienced students may need more. It also depends on you: You and your co-mentor(s) select the student and project you mentor, so you can choose according to the time commitment you have. Some mentors even do pair programming with their students!)

I recommend at least one mentor has a weekly 1hr meeting with the student so they get to know each other, keep everyone on track, and give a chance to talk about other stuff. Lots of students have questions about jobs, courses, architecture, open source, etc. and it's nice for students 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 students 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 students.

Mentors don't have to be the Best At Everything. A lot of what mentors do is keep students 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 students understand why features make sense (or dont!), system administrators can help student understsand how deployment works in practice, experts in areas like accessibility, usability, and security could help guide students in their areas of expertise.

Evaluating students

Mentors do have to do multiple evaluations on the student, 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 student is doing and then a pass/fail that determines if the student gets paid and continues in the program.

Sub Orgs

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. Have one sub-org admin and at least two mentors who are willing to commit to the full GSoC period. (More is awesome!)
    • If you want to connect with more potential volunteers, email gsoc-admins@python.org to see if we can match you with volunters who don't have a project.
  3. Accept the Python Community Code of Conduct for the duration of the program.
  4. 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 student applicant later and want to sign up just for them).
  5. Have a good ideas page. We have a template below. Getting a really great page sometimes takes a few rounds of revisions; Meflin will work with you to make sure your page is ready! Once you're ready for review, you can send a pull request to get added to this page
  6. 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.
  7. Disclose all potental conflicts of interest to the Python admins BEFORE accepting a student. If you are unsure, ask. If a conflict is found after the fact the student and sub-org may be dropped from the program. (Examples: student is involved in your research group, student is your child, student owes you money, etc.)

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 students 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 students to find projects that best suit them!

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 students 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 students 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 students introduce themselves first or just dive in? are there any common mistakes students 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 students 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 students 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 student can understand, as well as deeper details
  • Skills: programming languages? specific domain knowledge?
  • Difficulty level: Easy/Intermediate/Hard classification (students 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 the students to read first? bugs/feature requests?
  • Potential mentors: A list of mentors likely to be involved with this project, so students know who to look for on IRC/mailing lists if they have questions. (If you've had trouble with students overwhelming specific mentors, feel free to re-iterate here if students should contact the mailing list to reach all mentors.)

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.