Are you an experienced sprint facilitator? You can probably just run down the checklist.
An issue sprint is a two-hour activity for Drupal user group meetups. The goal of the Drupal Ladder initiative is to get 1% of active users on drupal.org contributing to Drupal core by 2014, and these sprints are the vehicle to reach that goal.
At issue sprints, people pair up into issue teams and work on issues in the Drupal core issue queue. With a little bit of sprint preparation, even people who have completed only the first few lessons on the Drupal Contribution Ladder can make meaningful contributions to Drupal core.
This guide can seem long or overwhelming, but don't worry: you don't have to know it all. Keep in mind, the first groups to organize these sprints were just making it up as they went along, and they turned out just fine. More than anything, this is just a list of lessons that they learned along the way.
Scheduling A Sprint
The first step to running an issue sprint is to get it on the calendar.
Gauge interest. The number of attendees at your sprint will vary depending on the number of Drupal users in your area, and how interested they are in contributing to core. You may want to post a poll on your local group and just ask for a show of hands at your regular meetup.
Find a venue. Once you know how many people to expect, you'll know how much space you'll need. To hold a sprint, you'll need tables and chairs, and steady wireless, at the least. Try to find somewhere private: for example, a coffee shop has tables and wifi, but many distractions that will keep attendees from making progress on their issues. It's also nice to have a projector available, so you can walk attendees through things by demonstrating on the big screen, and maybe a whiteboard so you can write down the wireless password or other info.
Offices tend to be the best option, because they have all these things. Are there any local Drupal shops with large conference rooms? Does your local library have a large meeting room that can be reserved?
Get it on the calendar. Schedule a two-hour block with your venue, and publicize it to your group at least two weeks ahead of time. This gives people enough time to make plans, arrange a babysitter if need be, that sort of thing. Publicize the sprint wherever you can: post about it on Twitter. Post an event in your local group on groups.drupal.org. If there's a local Drupal group on Meetup.com, make sure it's posted there.
Preparing for the Sprint
About a week before the sprint, start preparing to facilitate the event.
- Get an account on drupalofficehours.org (aka doh.org). This handy task-tracking tool was built by the folks behind the core mentoring hours. It is used to keep track of Drupal core issues that are good for novices, and the tasks necessary to bring them to completion. This tasks are things like confirm a bug, write a patch, write a test case, manually test the patch, update documentation, etc: there are several tasks to complete in order to finish up an issue.
- Read the mentor instructions and the facilitator instructions. Keep in mind that these were written for those who help out with the weekly core mentoring hours on IRC, so the information is not all relevant to your issue sprint; for example, you won't be helping people through IRC at all. Pay attention in particular to the sections about working with the tool.
- Poke around drupalofficehours.org and just get a feel for it. Make sure you understand how the site works. If you have questions or add some data by accident, contact Brock for help.
- Identify issues for your attendees to work on. drupalofficehours.org will probably already have some tasks in the Active Tasks list, but add some more to make sure you've got enough for all of your attendees, and enough variety to cover the variety of skill levels that will be present.
Look through the Drupal core issue queue for tasks to add for your sprint (need some guidance?). When you find one, follow the instructions on adding tasks to load it into the tool. If you'd like, set the Sprint tag to the name of your group, to indicate that your group is working on it. Repeat this process (it'll get quicker as you get used to the task adding form).
As a rule of thumb, aim to have as many tasks as you will attendees: attendees will pair up to work on issues, so you should only need half as many tasks as people. If you gather as many tasks as people, you should have enough variety to meet everyone's skills—and enough extras that people can start a second task if they finish their first.
- Identify issue team leaders. As noted before, your attendees will break up into pairs and work on issues together. This works best if one person in each pair is familiar with the issue, and knows how to go about making some progress on it. Identify people who would make a good "leading partner," and contact them directly to ask if they will lead the efforts on a particular issue during the sprint. This will help get the sprint running more quickly, because there will be attendees who are ready to begin working on an issue, and can get their partner up to speed quickly.
- Load the issue team leaders into the issue tracker. When attendees agree to lead on particular issues, add them as a mentor on the task for the issue. Make sure that the attendee has an account on drupalofficehours.org, and that you know their username. Open the task and click Add Attempt, and put the issue lead in the Mentor box. Leave Participant empty for now: this will be filled in when attendees pair up at the beginning of the sprint.
Running the Sprint
It's show time! Running a sprint is pretty straightforward, if you've done all the prep work.
- Give a quick introduction to the Drupal Ladder. This only takes a minute: explain the goal of getting 1% of active Drupal.org users to contribute to core. That's about it, really.
- Give a quick outline. From the attendees' perspective, it's helpful to know what to expect from the evening. Just run down the list: we're going to do quick introductions, then take a look at the list of available tasks, and break off into pairs as everyone finds a task that's well suited to them. Explain that the goal for the sprint is that every pair will make some progress on their task, whether it's a patch or a comment explaining some additional information about the bug or feature in question.
- Do quick introductions. Urge attendees to keep it brief. Something like, "My name is John Smith, and I'm a developer at ABC Corp. I've been working with Drupal for two years and have contribute a few modules."
- Suggest that attendees log into IRC. Being in the chatroom makes it easier to share links among attendees, and people who aren't at the sprint can chime in to help answer questions that are posted there. Attendees can join #drupal-ladder on freenode or use the web-based chat client.
- Ask attendees to create an account on drupalofficehours.org. Have them pull up the active task list. If you used a sprint tag when adding the tasks, you can add this to the end of the URL to get just the tasks you've tagged. For example, those from CapitalCamp 2012 can be found at http://ladder.drupalofficehours.org/tasks/capitalcamp2012.
- Have attendees pair up. Ask everyone to quickly look over the list of tasks and identify one that they would be able to work on. Those issue team leaders that you lined up already will work with someone interested in their issue (and maybe ask around to find someone who would like to work with them). Everyone else should focus their task search on those tasks that have a mentor listed in the Participants column, since those are the pre-arranged issue team leads. If there aren't enough of those leads lined up already, no big deal: attendees can team up and work on any task, as long as at least one of the two knows how to get them started.
- Get down to business yourself. If you can, team up with someone yourself and get to work on an issue. This sets a good example for other people to get started quickly, and there's no reason you should miss out on the fun. In my experience, it's difficult for the sprint facilitator to make much progress (since other people will have a lot of questions for you), but it still helps set the tone if you at least sit down and start working on something.
- Find and load tasks into doh.org before the sprint. You don't want everyone to spend the first half hour (or more) of the sprint just looking for something to work on.
- Recruit team leaders personally before the sprint. Avoid putting out an open call on groups.drupal.org: you'll have more luck getting solid leaders if you approach them directly.
- If you can, feed people at the beginning of the sprint, since well-fed developers are happy developers. You might be able to convince a local company to sponsor the sprint and order some pizzas for you. Just make sure that you leave in some extra room at the beginning for food, so it doesn't interfere with what should be the focused working part of the event.
- Issue sprints are a two hour activity. Less than two hours isn't enough time for people to get oriented with a new-to-them issue, figure out how to make some progress on it, and post something meaningful in a comment on the issue.
- When scheduling the sprint, make it clear that people should come ready to work. Some people have arrived at sprints without a laptop, thinking that it will be more of a lecture or networking hour. I advise putting a prominent What should I bring? headline in the event announcement.