This is based on the Google Summer of Code 2013 application for SymPy to be an organization.

NOTE: Do not use any markup in this document. We have to copy-paste the text to the application. All URLs should be in plain text.

Why is your organization applying to participate in Google Summer of Code 2014? What do you hope to gain by participating?

From previous experiences, we've found that GSoC is an effective way to get students involved in the project, by coding on a specific task with a finite timeline.

It will be beneficial for the project and the students, who will get the chance to write code for an open source project (and get paid for it).

Our participation from the past three years as an official mentoring organization has been very successful. A full reports are available at https://github.com/sympy/sympy/wiki/gsoc-2011-report, https://github.com/sympy/sympy/wiki/gsoc-2012-report, and https://github.com/sympy/sympy/wiki/gsoc-2013-report. We received boosts to many parts of our code base as a result.

Almost all of these projects would have never happened without GSoC, as our active community members would not have the time to do this work. Or, as is more often the case, they would not have the background knowledge to do the projects. Due to the highly technical nature of SymPy, many projects require an advanced knowledge in some mathematical area to complete. GSoC gives us the opportunity to find people capable of completing such projects.

At the time of this writing, half of the core developers with push access to the main development repo originated as GSoC students (6 out of 15), including the lead developer. Without this program, it is unlikely that any of them would have ever joined the project.

How many potential mentors do you have for this year's program? What criteria did you use to select them?

We currently have 9 mentors signed up (see the bottom of our ideas page, https://github.com/sympy/sympy/wiki/gsoc-2014-ideas). They have been chosen from members of the community who have shown themselves to be committed to the development of SymPy. This means that they will be familiar both with the code base and with git, so they will be able to help the students effectively with these. Also, we put lots of effort in choosing mentors who are familiar with the concepts that the student will be implementing. In SymPy, these are often mathematically complicated, so it is useful to have a mentor who understands them well. And of course, if someone whom we feel meets the above qualifications wants to mentor a particular student, we will let him/her, because that person is the most likely to be the best person to stick with that student and help him or her to complete his project.

In particular, fifteen people have push access to the main SymPy repository at the time of writing this text. Those are people that have already proven to be part of the SymPy community and proven that they can be trusted. This is an obvious pool of people to choose from. However, in the past, we also had excellent experience when we choose a mentor from outside this pool, for example a university professor familiar with the field of the project. In that case, we assigned a backup mentor from the above pool, so that the student can work with both and has a guidance as how to write his code and get it in.

In 2011, we made a big push for students to be active in the community, so that instead of just talking with their mentors directly, they ask questions on the public mailing list or IRC channel, where even if the mentor is the only one to answer, everyone will see and have a chance to comment. We found that this led to a huge increase in involvement after the program. Five of the nine students from 2011 are still active in the community a year later, and three are still active today. In contrast, only one of the five students from 2010 was active a year later.

Therefore, one of the key roles of the mentors will be to push the students to participate openly as much as possible. Thus, though it will still be the mentors' responsibilities to ensure that their students are not slipping behind, and to make sure that their code gets reviewed, the whole community will serve to "mentor" the students in that they will follow their work and participate in design discussions. In the past, we have even had members of the user community be active in certain projects that were exciting new developments, leading to things like pull requests against students' code.

What is your plan for dealing with disappearing students?

To begin with, we will try to pick students who will not disappear. We require all students to have submitted at least one patch that passes review and is pushed into the code base to be accepted. This will show that they are dedicated, because they must be willing to learn the code base enough to try fixing part of it, and be willing to stick around for the review process. It will also help prevent us from accepting students who are unable to complete the project by ensuring that they are competent enough to submit at least one patch. The patch submission process requires that the student communicate with the community in the review process, especially since first patches tend to require work before they can go in, so this will help us to determine the student's level of communication. As was mentioned before, we have found a strong correlation between level of open communication with the community and success and permanence of a student.

We require each student to start a blog, if they don't already have one, and to blog once a week about their progress. We will additionally require that the mentors and the students meet at least once a week, by whatever method is best for the two of them (email, the mailing list, IRC, etc., though we encourage those methods that are public to the community). However, we will also try to get the students to stay in touch with the entire community through the mailing list.

We will also require that students push their work to an online git repository at GitHub, so that the mentor, as well as everyone in the project, can monitor their progress and to see the things that they are doing, as well as to help them fix mistakes early. Not only should they push their work to a branch, but every time they have work completed, they should make a pull request with that work, so that the mentor and the community can start reviewing it, and so that it can be pushed in as soon as it is ready, so that it doesn't grow stale.

If, despite these things, a student disappears, or does not work up to his or her potential, the mentor and the SymPy organization admins will try to sit down with the student in an IRC conversation or via some other medium to try to see what is holding him or her back and how he or she can be brought back on track. If necessary, we may need to adjust the goals as originally stated in the student's application, because it is better for a student to do a reduced amount of work than to do nothing at all. If the student stops being responsive, we will require him/her to report daily on what work he or she did, or suffer failure.

If that doesn't help, then before failing him or her, we will raise the issue among all the mentors. In the past it was discussed with the Python Software Foundation, who was the umbrella organization. As a standalone organization, we will try to discuss this (privately) with similar organizations, like the Python Software Foundation, to get an outside opinion. If there are any doubts, we will also use the main GSoC list for mentors. This is so that we can make sure that the student was not treated/failed unfairly.

If nothing works, and it becomes clear that trying to get the student to work is a waste of our mentors' time and Google's money, we will fail the student in his midterm or final evaluation. But this will be a last resort, because it will be to everyone's benefit if the student can be brought back on track. We believe that it should not come as an honest surprise to the student if he or she is ultimately failed.

From the students that SymPy had so far, one project had to be ended at midterm, and we followed the above procedure in that case.

What is your plan for dealing with disappearing mentors?

Traditionally, SymPy has had a lot of willing backup mentors. We are in frequent contact with all our mentors and we have collaborated with each other for several years, so we do not expect that such thing would happen. However, we will assign a backup mentor for each student just in case.

Many of our mentors have mentored with us in the past, so we have an idea of how reliable they are. We will be more cautious with new mentors, being sure to always pair them with a more seasoned mentor.

Furthermore, we encourage students to interact with the whole community, and ask the whole community for help (i.e., on the IRC channel or on the mailing list) if they have a problem, rather than asking just one person. This will help them to become better members of the community and will also make it easier for the whole community to monitor their progress, as well as increase the chance of the students to stick around after the GSoC is over. Hopefully, in the unlikely case that a mentor disappears or even if he or she has to become less available for a little while, it will not be a huge issue for this reason. Additionally, in the past, exceptional GSoC students have helped each other out, though obviously we will not rely on this happening.

We will also make sure to not request or assign too many slots. For example, if we have ten mentors, then we should not request ten slots, because that will stretch us too thin, an there will be no backup people if a mentor disappears. It would be better to only request five slots in that case.

If, given the above, there is still some problem, both of the admins, Aaron Meurer (the current project leader) and Ondřej Čertík (the former project leader) are ready to step up and become a mentor or co-mentor for any project if needed.

As shown by the past years of our experience with GSoC, this model seems to work very well for us.

What steps will you take to encourage students to interact with your project's community before and during the program?

We require all applicants to submit a patch to the project that gets reviewed and pushed in (see https://github.com/sympy/sympy/wiki/GSoC-2014-Application-Template for a full list of our requirements). We do not require that this be a particularly complicated patch. In fact, we will reference to them the easy to fix issues in our tracker:

http://code.google.com/p/sympy/issues/list?q=label:EasyToFix

This is so that we can make sure that they can submit a patch and use git (if they can't we teach them at this stage) and also so that we have some experience with how they interact over email and other communication media. We will communicate with them very frequently before they are accepted, and try to get them involved in our community. If we find that a student cannot do these fundamental things, then he or she will not be accepted to the program, even if their work and application are otherwise high quality.

During the program, they need to blog once a week about their progress and are encouraged to become active members of our community. The mentors will also have a meeting with the students regularly (once a week) to monitor their progress. We will leave this up to the mentor and the student to schedule, because they may have problematic schedules to synchronize, but we will encourage them to do any meeting publicly, such as on our logged public IRC channel, so that it is public to the entire community. If it is more accessible to the mentor and student to meet in over some other medium (e.g., over phone or in person), we will ask them to provide minutes of the meeting somehow (for example, on the student's blog).

In general, we will try to teach the students that it is better to do things publicly. For example, we will encourage them to ask questions on our mailing list or IRC channel rather than over a private email or private IRC chat. Even if the mentor is the only person who responds to the question, the whole community will be involved. This will teach the student good habits about interaction in open source. In the past, we have found that it is those students who have these good habits who tend to stick around. As noted in a previous question, in 2011 we made a big push to do this better, and it resulted in a huge increase in the number of students who stuck around after the program.

What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes?

This year we plan to require each student to spend at least 10% or more of their time in reviewing other people's pull requests (PRs) (most of these will invariably be from other GSoC students, since they tend to be the most active contributors during the summer time). That way, they will become more integrated in our community and hopefully more likely to stay after the GSoC is over. Historically, students that were active in our PR queue were more likely to stay afterwards.

Making sure that the accepted students stick around has been the most important thing for us (besides their actually finishing their projects), because that is the only way to grow our community. We do not view GSoC as a two month program, but rather as a great opportunity to get more people involved with the project on the long term.

We have found that the most effective way to get students hooked in is to directly encourage them to post and discuss issues on our public mailing list and to publicly help other people (not just other GSoC students but anybody who needs help).

After the program is over, the students already have their blogs, which are synchronized with http://planet.sympy.org/, and usually if they blogged interesting things, they already built a nice community around their blogs, and so they continue blogging about what they do (for example, on that site right now, many of the recent blog posts are by prior GSoC students who have stuck around and continued to work with the community).

It all depends how they like our community and how they communicate with others, so we will try hard to make them feel comfortable so that they will stick around. This is how we treat all contributors to our project, not just GSoC students, because we have found that it's the best way to get people to contribute again.

We do encourage all students to stick around and become regular members of the community. Sometimes they do, and become valuable contributors and sometimes they even participate in Google Summer of Code again in future years, either as a students again or as mentors. Other times, they move on to do their own things, though often they will still sometimes submit bug reports or patches. We will try to accept students who are likely to become regular contributors to the community after the program ends, because that will benefit SymPy the most. But we do realize that people can become interested in other things, so while we do not require this of students (if it were even possible to require such a thing), we let them know that our expectation, as well as the expectation of the GSoC program, is to "contribute to open source, while getting paid, and stick around later and contribute more," as opposed to "getting paid, while contributing to open source, and move on after the job is finished."

Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here. (not required)

Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here. (not required)

We'd like to vouch for the PyDy project (http://pydy.org). The PyDy project aims to build the tools needed to derive, simulate, and visualize multibody dynamic systems (i.e. robots, musculoskeletal models, vehicles, machinery, etc). SymPy currently hosts PyDy's core package, mechanics, which symbolically derives the equations of motion of multibody systems. PyDy has and will continue to have a symbiotic relationship with SymPy but the PyDy project is growing to encompass aspects that do not necessarily fit inside SymPy's code base, so they are starting up an independent project to house the new software. PyDy was birthed from three previous SymPy related GSoC projects and, we'd like to vouch for their ability to mentor students under the GSoC program and maintain a quality project.

PyDy participated in GSoC last year under the umbrella of the PSF. Jason Moore, in particular, their org admin, did an excellent job of mentoring their student, and two of our students last year had projects closely related to the mechanics module and were mentored by PyDy contributors, as with help from Jason.

If you chose "veteran" in the organization profile dropdown, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year.

The SymPy project participated in 2007 under the umbrellas of the Python Software Foundation, Portland State University, and the Space Telescope Science Institute. We had five students in total. All five projects were successful. All the projects details can be found here:

https://github.com/sympy/sympy/wiki/GSoC-2007-Report

In 2008, we participated under the umbrella of the Python Software Foundation and we got one student, who was successful. All details are here:

https://github.com/sympy/sympy/wiki/GSoC-2008-Report

In 2009, we participated under the umbrella of the Python Software Foundation and Portland State University, for a total of five students. All but one were successful. Details are here:

https://github.com/sympy/sympy/wiki/GSoC-2009-Report

In 2010, we participated under the umbrella of the Python Software Foundation and Portland State University. There were five students, all of whom were successful in their projects. The details are here:

https://github.com/sympy/sympy/wiki/GSoC-2010-Report

In 2011, we participated as an official mentoring organization for the first time. We mentored nine students, all of whom were successful in their projects. The details are here:

https://github.com/sympy/sympy/wiki/GSoC-2011-Report

In 2012, we participated as an official mentoring organization for the second time. We mentored six students, all of whom were successful in their projects. The details are here:

https://github.com/sympy/sympy/wiki/GSoC-2012-Report

In 2013, we participated as an official mentoring organization for the third time. We mentored seven students, all of whom were successful in their projects. The details are here:

https://github.com/sympy/sympy/wiki/gsoc-2013-report

A total of 37 out of 38 GSoC projects (36 out of 37 students) were successful, and they incredibly boosted SymPy's development. Some of the students who did this program have continued developing for SymPy after the program ended, again helping to boost the program. Not only are these students sticking around and writing code, but many have come back as mentors, both for the Google Summer of Code and Google Code-in programs. For example, the current SymPy project leader (Aaron Meurer) participated in 2009 and 2010. In 2011, Ondřej Čertík, the founder and leader of the project, asked him to step up and be the leader of the project. Aaron would have never have heard of the project and would not be doing any work at all for open source were it not for the Google Summer of Code program. Last year, five of the seven mentors were previous GSoC students.

For almost all of the projects, it is almost certain that they would have never been coded if it were not for the Google Summer of Code program, because they were implemented by students who otherwise either would not have known about SymPy or else wouldn't be able to dedicate their summer to working on it without the stipend. The rest of the community would not have been able to implement the project themselves in most cases, due to lack of time, and, in most cases, lack of knowledge required to implement the project.

If you are a new organization, have you applied in the past? If so, for what year(s)? (not required)

Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application? (not required)

• GSoC-2014-Ideas -- Ideas for Google Summer of Code projects
• GSoC-2014-Application-Template -- The template for student applications for Google Summer of Code.
• GSoC-2014-Current-Applications -- A list of active proposals.
• GSoC-2013-Report -- Report for the GSoC 2013
• GSoC-Previous-Applications -- Some examples of successful Google Summer of Code applications from the past.