While working on a resources page for commit best practices, I ended up in an interesting conversation with Scott Murray and Camille Fournier on the review process. Scott asked the question, "How can I ensure a contribution is good before I click 'merge'?"

What a great question! How subjective! How arbitrary! How do we define "good"!

I took the time to combine a few of the resources I've worked on in the last year into a single resource page, The Review Process. Right now the document builds on the documentation that I worked on with Joe Shindelar last year when I was the Project Manager at Drupalize.Me. (New to PMing? You might also be interested in reading Things I Learned From Managing My First Project.) It adds some resources on dealing with additional remotes (relevant if you're using a forking permission structure, as is common for open source projects as commonly seen on GitHub), and it also adds some tips on being a good reviewer (cribbed from an article on code review I wrote last year for O'Reilly).

The resource is far from done, especially considering it only covers one of the four models for review outlined at the beginning of the document; however, if you're looking for a starting place to begin incorporating peer reviews into your own workflow, I think there are some valuable tips waiting for you in this new resource.