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.
Would something like that suffice? Visually indicate and internally store
which diffs you've read vs. the ones you haven't, and allow for quick
filtering of which ones you have or haven't seen.
I would personally like a model like this, though I think we'd have to play
with it a bit. I want to know if it would work for your needs, though.
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.
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com
On Fri, Aug 27, 2010 at 9:34 AM, J Arrizza <cppge...@gmail.com> wrote:
> I agree with you as well. However, when someone does publish a massive
> review, I have no recourse.
> Here are some suggestions (and only suggestions, meant only to get some
> conversation going):
> - allow me to put a comment at a file level (i.e. not on a line number
> within the file). I can use that to indicate "OK".
> - allow me to put a status on a file. A status is just an "ok/not ok"
> indication, no text can be entered. Then allow the file status to cross
> revisions, i.e. whenever I view any revision, I get a complete list of files
> from all revisions. The only diffs I see are for the current revision, but I
> can see all statuses for all files.
> - allow me to put a status on a file, plus have RB keep track of the total
> number of comments for that file across all revisions.
> - have a status (ok/not ok) at the file level, one for each revieiwer.
> Initially the status is "not ok". A new comment on any revision for that
> file resets the file status to "not ok". All reviewers can then go in, look
> at the new comment and/or code fix, and reset the status (for them) to "ok".
> - allow me to remove a diff/file from the current review.
> - allow me to move a diff/file to another, new, review.
> - give me full GUI support for splitting up an existing review (whatever
> that means! :)
> Are any of these easy to implement given the current RB architecture?
> On Thu, Aug 26, 2010 at 2:34 AM, Christian Hammond <chip...@chipx86.com>wrote:
>> I'll second this. It really is beneficial to try to break up the changes
>> more. Preferably into logical changes (such as code to implement one part of
>> the functionality rather than an entire feature, or doing code cleanups in a
>> separate change), though if you're past the point where that makes sense,
>> even breaking it up into file paths (potentially based on who is most
>> familiar with certain groups of files) would probably help.
>> I've seen this a lot too, where really large changes of mine have sat
>> around because they're too long to review. Not only do people avoid them
>> initially (since it requires such a time commitment), but the feedback isn't
>> as good as it could be. Smaller changes receive better review and can get
>> into the product sooner.
> Want to help the Review Board project? Donate today at
> Happy user? Let us know at http://www.reviewboard.org/users/
> 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 http://www.reviewboard.org/users/
To unsubscribe from this group, send email to
For more options, visit this group at