At PyCon, we sprint. That is, once the conference is over, rather than peacefully going back home to recover from three hectic days of learning and networking at an unhealthy pace, we stick around and start coding with the people that we meet only once a year.
Sprints are fun, and different people attend for different reasons, but they all agree that there is something special about the sprints that would be hard to replicate from the comfort of your office or your living room. Here's what some of the sprint leaders have to say about the PyCon sprints this year.
Proximity
One benefit of sprinting that is often reported by project leaders is the proximity of other hackers. It can be people working on the same project who get to hammer out the specification of a complex feature. Sometimes it's the availability of sprinters working on other projects who have experience with something that's common to multiple projects: porting to Python3, setting up a continuous deployment system, localizing a framework, ...
The goal of our SchoolTool sprint at PyCon 2013 was to automatically integrate the SchoolTool Quiz component with the SchoolTool Skills tracker by generating skill scores from answers to quiz questions which are already tagged with the skills they evaluate. A rules system was designed for this. (https://bugs.launchpad.net/bugs/1156385).
The feature was developed and 3 functional Selenium tests were added. At the end of the sprint it was deployed to the production server and has been used since. We also fixed a bug related to deploying quizzes to sections (https://bugs.launchpad.net/bugs/1092580). We had one user, acting as "customer", and three developers (two high school seniors and a SchoolTool developer) and received support from the #schooltool channel in IRC.
The sprint provided the first opportunity the team had of working side by side. The benefits of proximity enabled the professional developer / mentor to observe first hand the student's coding practices and to give them pointers. We all thought is was really cool to be sitting in the same room with Luminaries from the Zope and Pyramid communities working on software.– Douglas Cerna, sprinting on Schooltool
We closed 10 issues, redesigned the documentation, attract and tutor three new coders during all the sprint, a remote Russian contributor wrote a full tutorial on RESTful APIs with CherryPy, a new release and from my perspective a healthy reactivation of the development of the project.
We had around 10 to 12 contributors, varying from day to day.
An sprint is a great way to increase engagement with a project, both for the newcomers and the core contributor both ends feeds from the presence of the other, it accelerates the learning process and creates a closer relationship with your peers and the project itself.– Joel Rivera, sprinting on CherryPy
With 3 new contributors, [we worked] on fixing Python 3 compat issues. Another scikit-learn contributor also worked on a new pull request to improve the documentation in the afternoon.
In terms of commit it's 57 (including merge commits): https://github.com/scikit-learn/scikit-learn/pull/1790
The Python 3 support is not yet 100% done but this is already much better than previously.
The PyCon sprints are awesome in general to get to know new people and get new contributors understand the github contribution workflow quickly by mentoring them. It's also a good opportunity to speak face to face with other project members of tricky issues that would require long mailing list discussions to achieve the same understanding.– Olivier Grisel, sprinting on scikit-learn
The most valuable aspect of this year's sprint was a combination of the above (getting new folks involved) and having some non-code-yielding high level discussions with more advanced users.
- Achieved a handful of ticket closures (maybe ~5-10);
- ~8 contributors onsite;
- At least 2 folks contributed their first OSS pull request with us and another 1-2 contributed their first Fabric pull request.
– Jeff Forcier, sprinting on Fabric
The purpose of django-deployer is to make it easier to configure your Django project to be able to deploy it to a PaaS provider. Currently, there is support for Dotcloud and Stackato and I'm happy to announce that at the sprint we added support for Google App Engine. The code is available on Github and a release was recently made to PyPi, so you can try it out on your project today!
I had two persons working with me at the sprint, Colin Wu from Taiwan and Kyle Kelley. Kevin Grinberg and Wes Winham also provided input but no code contributions.
I love sprinting because it's an fun experience to get to work closely with other talented coders in an intense and compressed 2-5 days. You learn so much about best practices and how other people approach the problem.– Nate Aune, sprinting on Django Deployer
Bootcamp for new contributors
Becoming a contributor to an open source project can be intimidating. You have to use a common tool chain, you need to learn the accepted way to submit your changes and you need to become acquainted with the quality standards in place. Given all the unwritten knowledge involved, it's no surprise that many project leaders mention sprints as an ideal environment to welcome new contributors.
The PyPy team had a very productive sprints at this years PyCon. We committed 244 patches from 21 developers. We lowered the time needed to run our test suite, improved the support for string arrays in NumPyPy, removed old and unused code, and began some internal refactorings to simplify PyPy's code.
Sprints are a great way to develop open source software because they give a team that is normally totally distributed the opportunity to work with each other face-to-face. They're also a great environment to help get new contributors started.– Alex Gaynor, sprinting on PyPy
As I said at the sprint announcement session, sprints are as much about bringing developers into a project as they are about creating code: a bunch of established developers hacking together heads-down in a room might be productive, but it doesn't build community in the way a sprint does.
For the Zope / ZODB sprint:
- Prototyped / hammered out designes for a couple of approaches to cross- Python2-Py3k pickling in the ZODB.
- Created a pure-Python reference implementation of Zope2's ExtensionClass module (with the goal of running on PyPy; also opening a long-term option for a Py3k port).
- Various improvements to Py3k compatibility for ZODB.
- Fixes for a number of Zope2-related security issues (releases for 8 projects).
- Contributors: 6 onsite, 4 remote. At least one new contributor for ZODB.
– Tres Savor, sprinting on Zope and Pyramid
OpenHatch contributors, some old-timers and some fresh, hacked on our Django codebase and other web tools we use to help welcome new contributors to open source. Some especially remarkable changes are Marta Maria Casetti finishing a HOWTO guide any project can use for welcoming new contributors -- http://labs.openhatch.org/foss-contrib-guide/ -- and Rajesh Pradhan working over the weeks post-sprint to finish a serious refactoring of our codebase.
In-person sprints are a great way to have newcomers help each other learn git -- as ours did -- and for old-timers to share their knowledge and answer questions quickly so newcomers get unstuck as speedily as possible. Asheesh Laroia and John Morrissey mentored around 10 people in person over the course of sprints, resulting in new bugs filed, commits pushed, and mailing list discussion started from all the new people.– Asheesh Laroia, sprinting on OpenHatch
The Django project had 25+ sprinters in person at some point during the four days of sprints, plus more via IRC. Sprinters submitted twenty-six pull requests; merged pull requests included addition of a JSONHttpResponse, formset size validation, and several improvements to the documentation and test suite.
At least six sprinters made their first-ever contribution to Django. With experienced contributors and core committers on-hand to help, sprints are a great place for new contributors to get get started!– Carl Meyer, sprinting on Django
We had well over 10 people at the table on Monday, and dwindled to five by Thursday. Everyone who stayed for the better part of a day had a contribution merged. We also had a number of more experienced Buildbot developers present working on larger projects. Some of these projects are still in progress, and others have been merged, but lots of fruitful discussions took place during the sprints.
We probably had 20 people over the course of the sprints. While I didn't do anything special to encourage off-site sprinters, there was a noticeable uptick in IRC and pull-request activity during and after the sprints οΎ– I think a total of 3 new people contributed code that way.
For Buildbot, sprints are an effective way to bring people together to talk about the project itself, rather than how the project is used. They generate "buzz" and excitement about new work on the project, which helps to keep the overall momentum running.– Dustin Mitchell, sprinting on Buildbot
Meeting users
Platform and framework developers say that the sprints bring them unmatched opportunities to get in touch with the people using their code.
The best way to describe the value of the sprints for us would be to give the short list of things we've gotten done directly during the sprints (either entirely during sprints, or at least kickstarted):
This year was not as exciting (on paper) as last year, but we managed to:Last year was more exciting (can't always be this awesome!):
- Fix a medium-sized bug relating to resubmitting links on reddit
- Prototype integrating Mozilla Persona into our log in system
And, in both years, [we welcomed] several new contributors to the reddit code base. The trickiest part of our "open source" efforts has been our limited time to spend supporting users with their local development installs, so getting face-to-face time with people interested in setting it up is helpful in getting them going on helping us (and provides them with experience useful for setting up other projects). Sprints are a great way to encourage and grow our developer community, and provide that same community a chance to quickly work through a small feature or bug they'd like to see on reddit. In several cases, we've been able to roll out those bug-fixes/features to the live reddit.com site before the end of the sprint session (that was in 2012).
- Prototype OAuth2 support
- Automated API documentation (http://www.reddit.com/dev/api)
- 3-4 small bug fixes
– Keith Mitchell, sprinting on Reddit
This year the "Mython, Numba, and more..." sprint focused on making a clear division between the Mython language and the Basil framework. We moved development from Google code to Github, separating our Python pgen implementation into the mythonlang/pgen2 repository, and finished work on a new Mython syntax in the mythonlang/mython repository. We also registered both repositories with Travis-CI, allowing us to verify that pgen2 worked on Python 2.6, 2.7, 3.2, 3.3, and PyPy! We registered both projects in PyPI, including releasing a new source distribution for pgen2.
Despite having a single "full-time" contributor involved in the sprint, we benefited from interaction and support from the other sprinters present.
Sprints are a great way to do open source software development. Sprints provide a group with the opportunity to focus on their project, which may otherwise only be developed in small pockets of free time. Sprints also serve as a forum for both teaching and learning from a community of developers in a more personal manner than online. You can evangelize your project, and learn about other projects that could help you solve your problems.– Jon Riehl, sprinting on Mython and Numba
Spring cleaning
Many sprinters highlighted the fact that the timing of PyCon prompted them to take some time to work on their development infrastructure on cleaning their code rather than focusing on features.
Building momentum
Besides the immediate productivity during the sprints, attendees and project leaders agree that the velocity remains high event after everyone went back home.
pyelasticsearch had an amazing sprint, with 5 new contributors, including a new employee of the Elasticsearch company itself. Our 78 commits culminated in a 0.4 release, delivering Python 3 compatibility, support for 6 new APIs, lots of polish, and docs on migrating from pyes. Progress has continued at an accelerated rate even after the sprint, bringing clearer extensibility of JSON encoding, a new testrunner, and design work on a more flexible bulk API. Thanks to Hanno Schlichting, Honza Kral, Patrick Smith, Brian Jones, and Matt George for their great patches!– Erik Rose, sprinting on pyelasticsearch
Not just at PyCon
You don't have to attend PyCon to participate in a coding sprint! User groups and projects do it on their own when they have a craving for communal coding. If you want to organize a sprint, the PSF will help you: http://pythonsprints.com/.
Did we miss your project? Mention it in the comments.
Comments