In Scrum, what strategy should the team use to efficiently assign reviewers to tasks/stories?
A reasonable Definition of Done contains a requirement of code review:
The source code must be reviewed another programmer.
I'm interested in how the process of selecting a reviewer should interact with the board.
I've seen multiple approaches:
Scrum board isn't concerned with code review. Effectively, the author and the reviewer work together to move the task to the Done column.
This is quite flexible, but the downside is that the author must find a reviewer "behind the scenes" and convince him to spend time on the task. Sometimes the reviewer is not available/non cooperative (*). Sometimes both parties just forget.
There's a special column named something like "waiting for review". A reviewer takes a task and performs a review (gives OK or moves it back to "in progress").
This makes the process transparent, but it doesn't really represent what happens during code review. Usually, there are multiple exchanges or multiple commits, so the bureocracy feels unnecessary.
One commit per task on the board
This looks like an attempt to solve the problem from the previous point, but fails when the project is something more than a single git repository. This also creates bureocracy barriers for the good practice of focused commits.
The reviewer merges on OK
The reviewer merges a commit on OK and closes the task. This speeds up some bureocracy, but fails when the task involves additional work outside the repository.
(*) Especially when the developers are evaluated on the number of tasks closed/story points gathered.