[grault]

I'd be in favor of having some standard "code review markup language", which could contain review comments and workflows. Then you would be able to put these in files and make those files part of your repository (ie commit/push).

Then, you could build various frontends to handle these in a user friendly way if you like. But also, would be accessible and editable in your favorite text editor.

[blowski]

As long as the tools and processes don't get in the way of communication because they require comments to be written in a particular format or in a precise place. Too often, such tools end up in discouraging the very thing they're supposed to help.

[derwildemomo]

This is something I've been thinking about quite a lot lately – I considered extending our git-flow a bit to contain review branches (or something comparable). If you'd like to chat a bit about potential solutions for your approach just drop me a line!

[robinshen]

We solve this via gatekeeper rules (repository administrator defines rules such as who needs to review which part of code, or whose code needs to be reviewed (intern team for instance needs to be reviewed by core team etc), or what commit message rule should be followed etc.

A typical review process suggested by GitPlex can be found here: http://wiki.pmease.com/display/GP10/Iterative+Review+with+Pu...