There are a bunch of methods I've used over my software career. The one I found most effective was:
1)Create a review package with the code and a brief discussion of what it does. (if its an update then we'd provide code diffs).
2) Have reviewers (at least 3) submit a list of bugs to the person holding the review.
3)The reviewer could accept the comment or flag it to discuss.
4) Then everyone got together (meeting) and discussed the ones that where flagged to discuss. Generally this made the reviews themselves not last too long (going through every line of code thats fine is boring) and some interesting discussion could be had and a conclusion reached.
5)The moderator would write a ticket in the bug tracker for the items and then when the updates are made the moderator would verify the changes were made a close out the ticket.
Comments
There are a bunch of methods I've used over my software career. The one I found most effective was:
1)Create a review package with the code and a brief discussion of what it does. (if its an update then we'd provide code diffs).
2) Have reviewers (at least 3) submit a list of bugs to the person holding the review.
3)The reviewer could accept the comment or flag it to discuss.
4) Then everyone got together (meeting) and discussed the ones that where flagged to discuss. Generally this made the reviews themselves not last too long (going through every line of code thats fine is boring) and some interesting discussion could be had and a conclusion reached.
5)The moderator would write a ticket in the bug tracker for the items and then when the updates are made the moderator would verify the changes were made a close out the ticket.