I was in Tokyo for the Japanese PyCon over the weekend, and attended the developer sprints after the actual conference. This was my first ever time sprinting - it was a real blast. I’d like to share some reflections on a fun-filled day.

For the uninitiated, a sprint is a concentrated short-term effort to fix bugs, add features, etc. Sprint leaders are people who have a project they’d like to work on. The leaders pitch their projects to the sprint attendees, who then volunteer their time and workon the projects.

Typically, the leaders make their pitch in advance - for example, details for some of the PyCon JP sprints were up well before the conference, but last-minute pitches are also possible.

The sprint location was the Microsoft Office in Shinagawa. We had a large-ish conference room with an open layout, some whiteboards, free drinks, and a pretty awesome view:

I sprinted on two projects: piexif and pandas. This being my first time, I aimed relatively low so I could quickly get some runs on the board. It was a fairly productive day - I managed to wrap my contributions up as pull requests. The piexif one got merged almost immediately, while the pandas one shouldn’t take much longer to get through the review process.

I was very impressed by the preparations made by the sprint leaders @hmatoba and @sinhrks - thanks to them, I was able to get started and contribute relatively quickly. Below, I’d like to draw on the day’s experience and make some notes for my future self, in case I ever need to host a sprint in the not-so-distant future.

Be Prepared

Perfect Planning and Preparation Prevents Piss-poor Performance.

Prepare for the sprint beforehand. Have clear instructions for people to get started from the absolute bare minimum. For example, have instructions for setting up a GitHub account (or at least link to someone else’s). Have a list of specific issues that are good for getting started.

Examples:

  • one (Japanese)
  • two (Japanese)

Describe Issues Clearly

When authoring your issues (or tickets, whatever), include enough information so people other than your current self (your future self may have a completely different context when approaching the problem) can work on them.

If possible, write some tests that describe what the sprinters should achieve. This makes your expectations of the changes crystal clear.

Estimate Difficuly and Required Effort

Some issues are hard to solve. Others may be easy, but require a significant amount of time. It’s worth estimating difficulty and effort in advance, so people who are just getting started with the project can find the lowest-hanging fruit more easily (example).

Have Automatic Tests

This almost goes without saying, but make sure your project has automatic tests and clear instructions on how to run them. They will allow your sprinters to verify that their dev environment is set up correctly, and give them confidence that your project actually works. Last but not least, if their changes break anything, they’ll know about it early.

Bonus points if you’re using something like Travis CI for your builds.

Review Changes Quickly

Once your sprinters have made changes (pull requests), review them quickly, e.g. take hours/days instead of weeks. The longer you wait, the greater the chance that the sprinter will lose motivation and abandon the pull request.

That’s about it. Remember to have fun and sprint responsibly!