We faced the same and have come to a manual workaround.  We organize around
SCRs (Software Change Requests), with one review per SCR. This leads to a
complication in that each review can have multiple revisions (since an SCR
can have multiple changesets) and multiple files per revision.

Here's an example of our workflow. The example assumes 1 submitter (the
developer) and 2 reviewers since that's the way it is for us. Also it has 2
revisions because there were two changesets submitted by the
author. Revision 1 has changes to fileA and fileB, and Revision 2 has
changes to fileA and fileC.

   - Submitter creates a review
   - Reviewer1 goes to the diffs tab, selects Revision 1
   - He reviews fileA and finds no faults. He adds a single comment "OK
   file" at the first visible line. This isn't necessarily the first line of
   the file since RB displays the first diff +- context lines.
   - He reviews fileB and puts a comment in one of the diffs. He does not
   put "OK file" in this case.
   - He changes to Revision2 and finds all files to be ok so he puts "OK
   file" against each file there.
   - Reviewer2 goes to Revision1 and reviews fileA. He finds no problems and
   also places an "OK File" in the first visible line. Now anyone can tell that
   file has been reviewed since it has a "2" when it is viewed in the diff
   - He reviews fileB and if he finds no additional comments, puts an "OK
   file" .
   - He reviews Revision2 and also finds everything ok there too.
   - Submitter responds to the comment in File A
   - Reviewer1 goes into FileA and assuming he agrees with the submitter,
   puts an "OK" against the comment.
   - Now, since there are no unanswered comments in FileA, Reviwer1 also
   puts an "OK file" in the first visible line in the file.

In short, 2 "OK files" at the top of each file indicates the file review is
complete. When all files in all revisions have a "2", the review can be

There are complications and nuisances using this method but with people
willing to work around them it works ok. Clearly it would be much better to
have UI and automated support from RB but it is what it is.


On Wed, Jun 8, 2011 at 2:35 PM, Jeb <> wrote:

> I've read the docs and looked out on the web and haven't really found
> enough on this subject to satisfy me. Using RB seems pretty simple.
> Someone creates a review request. I review it. We iterate over the
> review, having these nice threaded discussions. Code is changed or
> not, finally it is submitted and closed. The tough part for me is
> knowing exactly when I've got work to do.
> 1. Bob creates a review
> 2. I respond to it asking for clarification on a few things
> 3. Bob responds
> How do I know Bob responded?
> Email - that's not enough for me, I don't rely on email to keep track
> of workflow issues like that
> New Comments Icon - what happens when I click the review and then mess
> with it -- that icon is gone and now it looks like any other review
> I just wish I could have some custom status or something where I could
> do the review, hit publish, then change it to "awaiting coder
> feedback" or something and have it show up in the submitter's incoming
> list.
> I'm sure I'm missing something, and I apologize for wasting anyone's
> time with this, but I could really use some help.
> Jeb
> --
> Want to help the Review Board project? Donate today at
> Happy user? Let us know at
> -~----------~----~----~----~------~----~------~--~---
> To unsubscribe from this group, send email to
> For more options, visit this group at


Want to help the Review Board project? Donate today at
Happy user? Let us know at
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to