Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
GSoC 2012 Organization Application
Clone this wiki locally
This is based on the Google Summer of Code 2011 application for SymPy to be an organization.
The application period opened February 27, 19:00 UTC and the application deadline was March 9, 23:00 UTC (3:00 PM PST).
I have submitted the text here on Melange. Please do not edit this page, even to correct a typo (except for the links section at the bottom), so that we have this for posterity. If you see something that you think should be changed, please change it at GSoC-2012-Organization-Application, which for now is just a copy of this.
Google will announce if we are accepted or not on March 16 at 19:00 UTC, and I will send a message to the list with the results at that time.
SymPy is a Python library for symbolic mathematics. It aims to become a full-featured computer algebra system (CAS) while keeping the code as simple as possible in order to be comprehensible and easily extensible. SymPy is written entirely in Python and does not require any external libraries, which makes it available everywhere Python can be used. It also has a liberal BSD license allowing other open source projects and commercial companies to make use of SymPy in their own projects.
SymPy has a vast array of potential applications, from theoretical physics (atomic physics, quantum field theory, general relativity, classical mechanics, quantum information...), applied math (solving algebraic and differential equations, ...), teaching (calculus, integrals, derivatives, limits, ...), web (it runs on the Google App Engine), and it can also be included as a library in any scientific code.
SymPy has a large, active development team that has increased non-stop since 2007 (ref: http://www.ohloh.net/p/sympy) thanks to an extensible architecture that enables features to be added easily and in a modular way.
It is built and tested regularly on all major platforms and all major architectures to ensure that it can reach the widest possible audience.
Organization home page url:
Main organization license (Note: this question has a popup selection for answers):
New and Simplified BSD licenses
certik (Ondřej Čertík)
What is the URL for your Ideas page?
What is the main IRC channel for your organization?
#sympy on Freenode
What is the main development mailing list for your organization?
Why is your organization applying to participate in Google Summer of Code 2012? 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, since each year this has proven to give a huge boost to the project, and it will be beneficial for the students, who will get the chance to write code for an open source project (and get paid for it).
Our participation last year as an official mentoring organization for the first time was very successful. A full report is available at https://github.com/sympy/sympy/wiki/gsoc-2011-report. See also the summary on the Google Open Source Blog http://google-opensource.blogspot.com/2011/12/students-add-to-sympy.html. All nine of our students last year passed their final evaluations. 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 nor, in many cases, the background knowledge required for the implementation.
This also boosted our community, as many of the students are still active. Indeed, at the time of this writing, almost half of the core developers with push access to the main development repo originated as GSoC students. Without this program, it is unlikely that any of them would have ever joined the project.
We have also participated in the Google Code-in. See the summary at http://google-opensource.blogspot.com/2012/02/google-code-in-students-simply-best.html. Thanks to that, many little things all over SymPy got fixed that otherwise wouldn't (SymPy Live improvements, mobile version of the site, translations of the site, our Sphinx documentation, doctests, docstrings and many other).
Before last year, SymPy had participated in GSoC under the umbrella of the Python Software Foundation, the Space Telescope Science Institute, and Portland State University. However, there is more competition for students applying under an umbrella organization, meaning that SymPy might not get as many students accepted as we would like or could handle. Also, umbrella mentoring organizations may limit what applications are accepted to work on SymPy based on what they see as being beneficial to their own organization, instead of directly to SymPy.
Did your organization participate in past Google Summer of Codes? If so, please summarize your involvement and the successes and challenges of your participation.
The SymPy project participated in 2007 under the umbrella 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:
In 2008, we participated under the umbrella of the Python Software Foundation and we got one student, who was successful. All details are here:
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:
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:
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:
A total of 24 out of 25 GSoC projects (23 out of 24 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.
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 because of 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 some cases, lack of knowledge required to implement the project.
If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)?
Does your organization have an application template you would like to see students use? If so, please provide it now.
What criteria did you use to select your mentors for this year's program? Please be as specific as possible.
Our mentors will be 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, if possible, we will choose 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, because that person is the most likely to be the best person to stick with that student and help him 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.
What is your plan for dealing with disappearing students?
To begin with, we will try to pick students who will not disappear. We will require all students to have submit 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. It will also help us screen students who will likely not be very communicative with the community, as these are more likely to disappear.
We will 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.). 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.
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 nothing works, we may be forced to 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. If the student stops being responsive, we will require him to report daily on what work he did.
If that doesn't help, then before failing him, 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.
From the 24 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.
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. Hopefully, in the unlikely case that a mentor disappears or even if he 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.
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 for any project if needed.
As shown by the five 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, during and after the program?
We require all applicants to submit a patch to the project that gets reviewed and pushed in. 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:
This is so that we can make sure that they can submit a patch (if they can't we teach them at this stage) and also so that we have some experience with how they interact over email. We will communicate with them very frequently before they are accepted, and try to get them involved in our community. As was discussed in the previous questions, if we find that a student cannot do these fundamental things, then he or she will not be accepted to the program.
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 on 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.
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. 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.
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.
Sage: The Sage project aims to gather all the great open source mathematical systems and put them together into a useful system. SymPy is among the mathematical systems included in Sage, and has been included in it since 2007. As a result, their community and ours often interact. For example, some of our community members, such as Ondřej Čertík and Fredrik Johansson, have participated in Sage Days, which is where members of the Sage community get together to work on projects in Sage. We believe that they are capable of successfully mentoring students as a mentoring organization. Feel free to contact us if you have any further questions.
Links (This is not part of the application)
- GSoC-2012-Ideas -- Ideas for Google Summer of Code projects
- GSoC-2012-Application-Template -- The template for student applications for Google Summer of Code.
- GSoC-2012-Current-Applications -- A list of active proposals.
- GSoC-2011-Report -- Report for the GSoC 2011
- GSoC-Previous-Applications -- Some examples of successful Google Summer of Code applications from the past.