Entry-Level Code Review Procedures?

Since September, half a dozen students at four universities have been rebuilding DrProject (our lightweight classroom-friendly replacement for Trac) on top of Django (a Rails-like web programming framework written in Python). What’s made this project different—and IMHO better—is the use of code reviews. Blake Winton, a local Python hacker, reviewed every single commit that came into the SVN repository in the first couple of weeks of the project. Thanks to his example, the students started reviewing each other’s work as well (Jeff Balogh, a two-time Google Summer of Code veteran who’s starting a full-time job with Mozilla in January, being the most prominent culprit).

It made a huge difference to productivity and code quality, and we’d like to do it again next term, but are wondering how best to implement it. We managed reviews this term by having each commit diff echoed to a mailing list; a self-appointed reviewer would reply to the email with comments, the author of the diff would reply, others would chip in, etc. I thought it worked pretty well (especially relative to the near-zero setup cost), but some students said in the post mortem that some commits got lost in the cracks, while others said they found it hard to track what was going on, since code review threads often turned into design discussions without a signal going to the larger group.

So, my question is, what could/should we do next term without either a big investment in infrastructure, or weeks of retraining? (I have no objection in principle to doing either, but since students only work 10 hours a week on this project, and usually have four other courses on the go, I have to focus on the absolutely smallest thing that could possibly work.) One suggestion has been to prepare a diff and send it to the reviewers’ mailing list before committing, so that reviews happen before code goes into the repo. Another is to pseudo-randomly assign commits to other team members for review (so that nothing gets dropped on the floor), and to use a “three strikes” rule to promote discussion from the review list to the dev list. What would you suggest? What do you think would work for a larger group (say, a class of 50 students, working in teams of 5, each team doing an 8-hour-a-week term-long project in parallel)?

In the wake of posts about Shopify's support for white nationalists and DataCamp's attempts to cover up sexual harassment
I have had to disable comments on this blog. Please email me if you'd like to get in touch.