-
Notifications
You must be signed in to change notification settings - Fork 0
GSoC 2013 Organization Application
This is based on the Google Summer of Code 2012 application for SymPy to be an organization.
I have updated this with this year's questions. Please edit the answers.
The deadline for the application has passed. Please don't edit this page anymore. If you want to make an edit, please edit next year's application.
sympy
SymPy
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 physics (atomic physics, quantum field theory, general relativity, classical mechanics and dynamics, quantum computing and information...), math (solving algebraic and differential equations, automatic code generation for finite element and other solvers, number theory, group theory, ...), teaching (calculus, integrals, derivatives, limits, polynomial algorithms, ...), web (e.g., it runs on the Google App Engine, see http://live.sympy.org and http://gamma.sympy.org), and it can also be included as a library in any scientific code. There are several commercial applications that use SymPy as the symbolic engine, including some in Google Play and the App Store. SymPy also acts as a core component for other open source projects such as the PyDy project (http://pydy.org).
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.
New and Simplified BSD licenses
Veteran
certik (Ondřej Čertík)
If you chose "veteran" in the dropdown above, 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
A total of 30 out of 31 GSoC projects (29 out of 30 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.
N/A
Why is your organization applying to participate in Google Summer of Code 2013? 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 from two years ago 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 that 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 5 of the 9 students are still active till today. Indeed, at the time of this writing, half of the core developers with push access to the main development repo originated as GSoC students (7 out of 14). 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 in 2011. 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). One of those students even continues to contribute to SymPy today, leading to things like a complete rewrite of SymPy Gamma.
Last year we had 6 students, and the overall boost to SymPy has been enormous as well. And again, few if any of the projects would have been done at all without the program.
Before 2011, 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.
https://github.com/sympy/sympy/wiki/GSoC-2013-Ideas
http://groups.google.com/group/sympy
#sympy on Freenode
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/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, fourteen 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. As noted above, five of the nine students from 2011 are still active in the community. In contrast, only one of the five students from 2010 was active a year ago.
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.
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 30 students that SymPy had so far, one project had to be ended at midterm, and we followed the above procedure in that case.
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, 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.
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 six 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-2013-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. 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, 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 that your accepted students stick with the project after Google Summer of Code concludes?
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). We also encourage them to review pull requests at GitHub of other people --- that is maybe the best way to get students integrated in our community --- and not be afraid to spent 10% (or even 20%) of their time doing just that.
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.
No.
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.
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.
- GSoC-2013-Ideas -- Ideas for Google Summer of Code projects
- GSoC-2013-Application-Template -- The template for student applications for Google Summer of Code.
- GSoC-2013-Current-Applications -- A list of active proposals.
- GSoC-2012-Report -- Report for the GSoC 2012
- GSoC-Previous-Applications -- Some examples of successful Google Summer of Code applications from the past.