This is a living document on best practices around Code Review Sprints. It is not a once size fits all, so do what is best for your specific group of people.
Goals
The goal of a Code Review Sprint is usually to teach and advocate about reviewing, and work on the application queue. Though getting through applications is awesome, building long term reviewers is more important as this is a much more sustainable outcome in the long term.
One of the cooler things about the sprint is the possibility of in person reviews where an applicant sits down next to a reviewer. So, don't just get
Audience
Who should be a Code Review Sprinter.
- Experienced Drupal coders (modules, themes, etc).
- Full Project Applicants
- Documenters. This could be the traditional kind, but this could be making video or audio. A flowchart of the process would be so cool!
- Advocates. This process and the team needs to grow!
- Review administrators. This person(s) does not necessarily have to be there in person but needs to be ready to do approvals, maybe via IRC.
In Person Sprints
There are a few key steps for doing an in-person sprint. Keep the following mind throughout:
- Always have clear instructions on what is going on and who to ask if people are confused. This could be a white board or something projected on a screen. It is can be very discouraging if someone walks into a sprint and everyone has their head down and you don't know what can be done.
- Have a list of things that people can do. Though actual reviews are the focus, there are other things like documentation, team building, facilitating, etc that can be done.
- Have a person to greet people as they come in (especially those who are early or late), help them get oriented with the instructions and tasks, pair them up if there are still pairs to be made, answer questions, and make them feel welcome. This person can also capture names/usernames and ensure that people are comfortable with having their name, photo, etc. published.
Teach
Your probably first step is to do some sort of presentation about how to review. This could include the following:
- History of the process. How we got here.
- A brief look at the goals of the process.
- How to review
- Go through an application (live or a previous one)
Here is the the presentation given at the PDX Code Review Sprint in May 2011.
Links
You should have the following things on a white board or projector:
- How to review
- Application workflow
- Application Queue
- Sprint tag
- Name of admin/facilitator
Pair up
Assuming that you are able to get applicants to attend, take a few minutes to pair people up. It could be possible that someone is applying with a module that integrates Drupal with EC2 and a reviewer present has lots of experience with that.
Review!
Go ahead and go! It might be good to tag all the issues people are working on with a specific tag, so that it will be easier to go back and look at what happened.
With most sprints, it is a good motivator to take a moment to ring out people's successes, like when a review has been completed.
Collect names
Collect the names or usernames of the people that were there and what they did. This is really helpful if you want to do a blog post summing up what happened, and it will help recognize the awesome work that was done.
Online Sprints
I think the main thing here is just to have one or two people in IRC to people to answer questions and link people where to be.