[bluehatbrit]

Our peer reviews are pretty standard, we have the same check list for everyone though anyone is always welcome to suggest changes to it (which are discussed separately to an individual peer review).

We also always try to frame feedback in regards to the code and project, and not the author. This attempts to make things less personal and helps us focus on the task rather than the individual completing it.

I guess the only other important thing to note is we always try to mix up review pairs / groups. We don't have that many people so this is very easy, but it means that we keep a nice mixed pot of ideas and thoughts rather than ending up in silos where Bob and Alice only review each others work and no one else gets overview of it.

Oh, we also try to make sure we pick out good things as well as changes we'd like to see. This is just generally encouraging and stops reviews being "what can you do better" and makes them more of a true look at the work as a whole. "Oh I love how you abstracted this module, it's made your code here much easier to understand" often makes people feel good about the work and gets them excited to make the few small changes the rest of the team thinks should happen.