Last updated March 26, 2012.
What is a code sprint?
A code sprint is getting developers for a set amount of time – usually one to two days – and just writing code. That's it. You’re not teaching anything. Participants will learn from others as they go, but the focus is not on instruction. The goal is to create working software. Code sprints are also sometimes called hackathons or codeathons.
Generic considerations for organizing sprints are described on the organizing sprints page. This page lists some considerations specific to code sprints.
In person sprints are indisputably the most effective way to tackle difficult code challenges.
You have a strong meetup and you have a strong camp presence and now you want to get some work done. Or you have been coordinating among several leaders in a given area of development and it's time to get them in the same room working together.
While nothing's quite the same as being in the same room, it's not always feasible to bring together people from around the world. It's also possible to organize a virtual sprint. Here communication might happen through IRC in a designated channel with set times for participation. Ideally, if some participants are in the same region or city, they could arrange to get together in small clusters so at least some sprint participants are in the same room.
A virtual sprint requires a bit more coordination and imagination but can also be effective.
Talk about what is going to be done at the sprint. Defining some goals and communicating them ahead of time helps for focus and preparation. For example, you could have a sprint focused on improving core themes.
Also try to define the minimum bar needed for participation. Unless you’re giving a newbie sprint, you need to communicate that this is not the place for newbies. If you’re coming to a theming code sprint, you need experience in theming. If you get a lot of people who aren’t up to speed on the code you’re focusing on, you pretty much have the first day of the sprint wasted. Everyone’s trying to figure out how things work, walking through the module trying to figure out what the functions are.
Make sure participants have access beforehand to the same files. If you’re going to be working off a single repository, make sure it’s available. If you’re not working directly off of Drupal git, make sure all participants have access and that you’ve tested your repository with multiple concurrent users.