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
GCI 2012 Organization Application
GCI 2012 Organization Application
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, so it can be used on any platform that can run Python. At the same time, SymPy can utilize other Python libraries if they are installed, including matplotlib, gmpy, and Numpy. In addition, SymPy employs 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, e.g., http://live.sympy.org/), and it can also be included as a library in any scientific code.
SymPy has a large, active development team that has increased consistently since 2007 (ref: http://www.ohloh.net/p/sympy). This is thanks largely to an extensible, modular architecture that enables features to be easily added and changed.
It is built and tested regularly on all major platforms and all major architectures to ensure that it can reach the widest possible audience. This testing is performed both by a testing tool developed by SymPy, sympy-bot (https://github.com/sympy/sympy-bot), and using Travis CI continuous integration service (https://travis-ci.org/sympy/sympy).
Why would your organization like to participate in Google Code-in 2012?
We believe that Google Code-in is a great opportunity to grow our development base, drawing in students who would not otherwise participate or even know about SymPy. With the changes this year to the winner selection process, we think that we can get quality contributors this way and some students might even stick around, possibly to participate in the Summer of Code program with SymPy some time in the future. Every outreach that we do with SymPy, be it GSoC, presenting at conferences and other talks, or being mentioned on the Google Open Source blog, usually brings us some new users, and generally brings new developers, even if it is just someone who submits a patch every once in a while, and we hope Google Code-in will do the same.
Our experience with the program last year was very positive. It resulted in bug fixes and improvements to both the SymPy core code base as well as projects like SymPy Live. Many of these were in areas that would likely not have happened without the program, either because they involved things that SymPy developers are generally not good with, such as web development, or because most SymPy developers would consider them too tedious or uninteresting. For example, here is what SymPy Live looked like before GCI last year (http://1.sympy-live.appspot.com/) and here is what it looks like now (http://live.sympy.org/). Virtually all of these changes were made by GCI students (a couple by students after the program).
Last year, a handful of students did contribute outside the program, and at least one student made a significant contribution, extending his work on SymPy Live to an extension that runs it on top of our documentation (see http://docs.sympy.org/, click "Run code block in SymPy Live" on one of the code examples). He also rewrote SymPy Gamma (http://gamma.sympy.org/), for which we plan to include several tasks this year.
Another reason we would like to participate in Google Code-in is it allows us to foster current SymPy developers, giving opportunities for mentors to collaborate in addition to recruiting new mentors, so the participation in Google Code-in helps the whole SymPy community. We have usually been quite efficient in accepting lots of patches from a lot of people, but every such opportunity is great to streamline our review/merge process even more and force us to think how we can lower the barrier of entry for new contributors.
What years has your organization participated in Google Summer of Code? If you have participated in Google Code-in or GHOP please also indicate those years.
- 2012 - 6 students
- 2011 - 9 students
- 2010 - 5 students under PSU, PSF umbrella orgs
- 2009 - 5 students under PSU, PSF umbrella orgs
- 2008 - 1 student under PSF umbrella org
- 2007 - 5 students under PSU, PSF, STScI umbrella orgs
Google Code-in: 2011
Google Highly Open Participation Contest: 2007
Please provide a link to your tasks page. This is one of the most important parts of your application as it lets us see what type of work you plan to have the students work on for Google Code-in. Please be sure to include at least 5 tasks from each of the 5 categories. This is similar to the Google Summer of Code Ideas page.
What programming languages does your organization use?
What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for Google Code-in 2012. If your organization uses more than one list, please make sure to include a description of the list so students know which to use.
Our main development list is firstname.lastname@example.org. You can subscribe at http://groups.google.com/group/sympy. All of our main communication goes through this list. If you have any questions, or just want to introduce yourself, the list is the place to go. We are very friendly and helpful on it, so don't be afraid to post. The list is relatively low-traffic, though that is expected to spike during the Code-In period.
We also have an IRC channel at irc://irc.freenode.net/sympy. You may be able to find help there. If no one on the IRC channel can help you, try asking on the mailing list. Note that IRC is not exactly like real-time chat, so consider that it might take a couple of hours to get an answer to your question (as the other developers might be busy and just leave their IRC clients on in the background). However, once people actually start talking about an issue, it allows for very rapid communication and is more practical for small questions than the mailing list.
The main people who will be helping out with Google Code-In are at https://github.com/sympy/sympy/wiki/gci-2012-mentors. Note that it is preferable to contact the mailing list than a specific mentor, as a specific mentor may not be able to help you with your specific problem, or at that given time.
Our issue tracker is at http://code.google.com/p/sympy/issues/list. All of our Google Code-In tasks are issues in either issue tracker or the SymPy Bot tracker at http://github.com/sympy/sympy-bot/issues, and are clearly marked with their Code-In category via labels.
All patches to SymPy should be submitted as a pull request to our GitHub organization at https://github.com/sympy/ (except for those where this is not relevant, such as improvements to the wiki). We have an extensive guide targeted directly to Code-In students on how to do this at https://github.com/sympy/sympy/wiki/gci-2012-landing.
What is the main IRC channel for your organization?
#sympy on freenode.
Please tell us about how your organization has prepared for Google Code-in, including what (and how many) mentors and organization administrators have agreed to help, what your schedule and response time will be during the holidays (and otherwise during the contest period) and how you plan to deal with unresponsive mentors.
These people have committed so far:
Admins: Aaron Meurer, Ondřej Čertík
Mentors: Aaron Meurer, Sean Vig, Matthew Rocklin, Bharath M R, Vishesh Kumar, Stefan Krastanov, Sergiu Ivanov, Vladimir Perić, Ondřej Čertík, Chris Smith
It is likely that others will help out too. For example, we had six Google Summer of Code students this year, and only two have committed to helping out so far (Matthew and Vladimir). Also, two or three core developers have not responded yet, but they will no doubt help out here and there with reviewing stuff. There was a surge of new contributors during the GSoC application periods for the last two years (as each applicant needed to submit one patch to SymPy) and it was handled fine. See for example the "More Stuff/Traffic" section of https://github.com/sympy/sympy/wiki/gsoc-2011-report. And now we have an even large community because many of our Google Summer of Code students from the past two years have stuck around. We were able to handle Google Code-In last year just fine, and this year we have more core developers again because of Google Summer of Code students who have stayed with the community. We also believe that the new Code-In rules this year will lead to fewer students, and those who do participate will be easier to deal with, because they will stick with SymPy throughout the program, and so we will not have to constantly teach them the basics.
As our mentors are from all around the world and are of varying religious persuasions, someone will be around for all holidays during the program.
Here is a detailed page with photos and short bios: https://github.com/sympy/sympy/wiki/GCI-2012-Mentors
SymPy doesn't have any mentor specific areas, so all mentors will have access to Melange to approve a task, and any trustworthy mentor will have push access to SymPy. As such, if some mentor becomes unresponsive, others can step in. So far, we never had any problem with disappearing mentors in GSoC. We have also participated in GHOP previously, without any problems. Or only issue with GCI last year was with translation tasks, because only specific mentors could grade those tasks, but because those are gone this year, we do not expect to have any issues.
We will require all students to submit patches through GitHub's pull request system (except for those for which this is not relevant, such as the tasks to improve the wiki). We have been using GitHub's pull request system since its inception last August, and it has greatly increased our productivity with respect to reviewing patches and pushing them in. Because of the high efficiency of this system, combined with a Travis CI and test running bot that we have been developing to run the unit tests on pull requests, we believe that we can handle the increase in pull requests that Google Code-In would produce. Also, all of our core developers would put priority on reviewing Google Code-In pull requests. As mentioned before, we handled this just fine last year, and this year we have even more core developers thanks to the 2012 GSoC students who have stuck around. Also new this year is that we have full automated and instant testing on every pull request update thanks to Travis CI, so the students will be able to see instantly if their work needs to be improved, even before a mentor has a chance to look at it.
We have already created over 100 tasks for Code-In (see the link to the Google Docs spreadsheet), and many more exist in our issue tracker and just need to be properly tagged and added to that spreadsheet. We have used our already existing issue tracker at Google Code (http://code.google.com/p/sympy/issues/list), as well as https://github.com/sympy/sympy-bot/issues for SymPy Bot, creating labels for the various Code-In categories. For our tasks, we will direct the students to the respective issue in the issue tracker, where there may already be some discussion about how to fix the issue. The new rule this year that allows mentoring organizations to add new tasks at any time during the program will allow us to add new tasks throughout the program based on what we see that can be done well by our students, including things that may extend work that they have already done. Our goal is to teach these students about coding and open source, and to hopefully convince them to stick around after the program. And hopefully, they will also learn some interesting math along the way.