There is one more aspect that I think is important. I look at the SCR as
the central unit of work, not the changelist/changeset.

RB seems to be geared towards

   one changeset <==> one code review

But from my perspective, the situation is more like:

    one SCR <==> one code review

That's why I want to put multiple files into a code review and multiple
changesets into a code review.

An SCR holds a single enhancement or perhaps a well-defined sub-part of that
enhancement. It has to be this way since external non-development people
consider an enhancement as a single change and track it, report it, and
think about it that way.

This also means that an SCR becomes a place to store evidence that we've
done everything in the development process we are supposed to do according
to our formal procedures. If everything is in a single SCR, it becomes much
easier to track and to report that all is ok, i.e. the SCR says the RB id is
nnn, the RB code review nnn says every code change was reviewed by every
reviewer, therefore the enhancement (aka the SCR) has had a complete set of
code reviews performed on it.

What this implies to RB is it should have the capability to:

   - add and remove files in a code review
   - add flags or checkboxes to each file for each reviewer to indicate the
   file was reviewed.
   - add flags or checkboxes for every comment to indicate the comment was
   addressed or re-reviewed by every reviewer.
   - The original version doesn't change and all subsequent diffs are
   compared against it. It is the version of code that existed before the work
   was started on the SCR.

   In other words, for a given file, the left hand side of the diff never
   changes, only the right hand side. If a file is updated, I only want to see
   the latest version. I would be ok with not seeing any of the intermediate
   versions/diffs. They just confuse the situation for outside observers (e.g.


On Mon, Aug 30, 2010 at 10:08 AM, J Arrizza <> wrote:

> Christian,
> Thanks for the response!
> >Have you used Google Reader? In Google Reader, as you scroll through a
> list of posts, it will mark the ones you've scrolled past (or interacted
> with) as "read." This makes it very easy to see all the posts or just the
> posts you haven't gotten to yet.
> I haven't used Google Reader, but I think I know what you mean, i.e.
> similar to the gmail, outlook etc that bolds the subject line? I think this
> would be good, but my preference is to make the indication more explicit.
> Just bolding or italicizing a file name isn't concrete enough since visual
> indications can be unconsciously ignored or inadvertently applied.
> In any case, it also has to be un-doable (just like outlook allows you to
> "mark as unread").
> >I could also see allowing easily hiding/showing of a diff. Kind of an
> expander (not diff chunk expansion) where you could collapse the entire
> thing down to one line with the file's name. That requires a bit more manual
> work to keep track of where you are, though.
> I think this and the above together would be a very powerful UI addition to
> RB. For example, I could "collapse all" which would show the entire list of
> files as a simple list, with the "ok/not ok" as one of the columns. Then I
> could very quickly find the file that's missing and review it. Also it's a
> great visual progress indicator.
> The caveat, I think, is the collapsed list has to show *all* the
> files, whether new, deleted, modified, in the current revision or not. That
> sounds more complicated for implementation but from a user perspective, it's
> a whole lot of nice-to-have.
> Of course, if RB could assist me by marking a file as "not ok" whenever a
> new comment is applied to it by any reviewer, I wouldn't object!
> > I want to know if it would work for your needs, though.
> I need assistance in tracking the changes developers are doing wrt to fixes
> based on reviews. The initial reviews are straightforward, but I need to
> ensure that they have, in fact, implemented the changes from the reviews and
> that the updates were also reviewed. Since initial commits are whole files
> and not just a few diffs, there can be a large number of comments per file
> and of course a large number of files. It quickly gets out of hand,
> especially when the updates for the comments are put in a few at a time or
> by different developers.
> In short, at the end of this process, I need to be able to state with
> explicit evidence that:
> - all the reviewers have reviewed the file by applying some positive
> indication, either a comment or an "OK"
> - all of the comments have been addressed, either by a code update or by a
> discussion indicating everyone agrees the code is OK as is.
> - all of the code updates were reviewed
> - ...and follow that tail recursion on down to the last turtle :)
> I can handle these by imposing rules on the developers, but having a tool
> guide the process is much much better.
> John
> (PS the "explicit evidence" is for the FDA and our internal quality folks
> but is applicable to any regulated environment, e.g. FAA, DOD, others?)

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