The author preparation feature (#4) could indeed be useful, sometimes it takes quite a bit of time, especially if one is not very familiar with the system, to see how they fit in.
We have implemented this using something we call the overview meeting, or the architecture meeting.
It is an optionally requested meeting at the beginning of the review process. In this meeting, the goal, the general structure of the software and the general structure of the changes are discussed on a high level for about 10 minutes. Afterwards, we decide which classes are focus in the review, which classes are kinda part of the review but boring. Sometimes the review is even removed because the changes are too small.
Overall, it's a very helpful meeting, especially for people new on a project. Confusion changes into understanding and focus with just a few words and a simple informal diagram and from there, very precise and productive code reviews follow.
Yes, this sounds like it is well worth the time. Not that in my current project it would be unthinkable to go and ask the original coder for some extra info but people tend to be busy and it tends to feel a bit like wasting their time.
* minor correction to my original post - "they" refers to the code changes
It is an optionally requested meeting at the beginning of the review process. In this meeting, the goal, the general structure of the software and the general structure of the changes are discussed on a high level for about 10 minutes. Afterwards, we decide which classes are focus in the review, which classes are kinda part of the review but boring. Sometimes the review is even removed because the changes are too small.
Overall, it's a very helpful meeting, especially for people new on a project. Confusion changes into understanding and focus with just a few words and a simple informal diagram and from there, very precise and productive code reviews follow.