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
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.
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.
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.
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.
To participate under the Python umbrella, a sub-org must do the following:
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.
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!
Tell the prospective contributors a bit about your organization. Here's some questions you might want to answer:
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?
Links to setup instructions go here. Some suggested things to answer:
Links to advice about applications and the application template goes here.
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.
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.