Who should be reviewed?
Everyone who submits code into a shared repository.
Who should do the reviewing?
A mentor or senior engineer who will look out for bad smells and errors in architectural correctness of the code.
Peers on the team or pod working in the same area of code i.e. if you are working on 3d rendering in a computer game, all the other graphics programmers should review the code.
Anyone else whose modules are interfaced by or dependent on the code being submitted.
What code should be reviewed? (all code? Big changes? Etc)
In my experience all code that is going to be worked on by more that one person (and that's almost all code).
Where should the review take place? (Does it have to take place in person?)
Reviews are most beneficial when they are interactive and real time. Having said that I think it's important to have a system like CodeReviewer to allow easy distribution of diffs so that reviewers can study the changes more efficiently and more comfortably within their own dev environment, before doing the actual face to face review.
I'm in no way associated with CodeBear, but I've always found my code reviews to be more effective when I've been able to view the changes on my own machine since I've got the IDE and tools and everything else configured just the way I need for me to effectively spelunk the code to see what impact the code changes will have and that is something I can't do if my review is all of 15 minutes at another person's PC watching them scroll through their changes.
When should reviews take place? (Incrementally? Before check-ins?)
Before check ins. I've been in situations where incremental code review amounted to me writing the person's code for them "incrementally" during each review. :(
Why should code be reviewed?
Two main reasons come to mind.
The first one is to preserve the quality and consistency of the code base. For any real world code base you will most likely have programmers of varying levels leaving and joining the team that's responsible for maintaining that code base and reviews try to minimize the code base becoming a reflection of the teams dynamics e.g. 2 crappy programmers joined the team last week and now 20 source files have crap in them.
The second reason is to remove tunnel vision assumptions in the code. At some point a code base will become too massive for one programmer to understand it all. And from that point forward everyone working on the code will have their own "slice of reality" about what the code does and how the system works and this will often lead to code being written that's based on naive or wrong assumptions. So having other people bring their view of reality to your code during the review helps reduce this problem of code base myopia.