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.

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com


On Tue, Aug 24, 2010 at 6:48 AM, Scott Quesnelle
<scott.quesne...@gmail.com>wrote:

> John,
>
> This isn't a software answer, but if the changes is that large, then we
> encourage the author to try and split it into pieces which provide a part of
> the whole solution. I.e a review of the server side change, another with all
> the database related changes, and a last one with the client side changes.
> This helps reviewers with being able to concentrate on the review.
>
> Many studies show that if a review is too large (generally takes more then
> 1 1/2 hours to go through) then the quality of review comments drop.
> Reviewing code requires a high level of concentration and that can only be
> maintained for so long.
>
> Scott
>
>
> On Mon, Aug 23, 2010 at 10:51 PM, J Arrizza <cppge...@gmail.com> wrote:
>
>> Hi,
>>
>> When initial code is put into RB or a large change is put in, there can be
>> many files (say 50). Can't really review that in one sitting so there needs
>> to be a way for a reviewer to keep track of which files he's finished with
>> (e.g. "ok with file xyz.cpp").
>>
>> I see that an issue was raised for this already (by Ben Hollis)
>>
>>  Issue 1772 <http://code.google.com/p/reviewboard/issues/detail?id=1772>: 
>> Allow
>> reviewers to check off files they've looked at
>>
>> In the meantime, has any one come up with a good workaround? I've thought
>> of just putting a comment that says "OK", but that could get messy
>> especially with email notifications...
>>
>>
>> John
>>
>> --
>> Want to help the Review Board project? Donate today at
>> http://www.reviewboard.org/donate/
>> Happy user? Let us know at http://www.reviewboard.org/users/
>> -~----------~----~----~----~------~----~------~--~---
>> To unsubscribe from this group, send email to
>> reviewboard+unsubscr...@googlegroups.com<reviewboard%2bunsubscr...@googlegroups.com>
>> For more options, visit this group at
>> http://groups.google.com/group/reviewboard?hl=en
>
>
>  --
> Want to help the Review Board project? Donate today at
> http://www.reviewboard.org/donate/
> Happy user? Let us know at http://www.reviewboard.org/users/
> -~----------~----~----~----~------~----~------~--~---
> To unsubscribe from this group, send email to
> reviewboard+unsubscr...@googlegroups.com<reviewboard%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/reviewboard?hl=en
>

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Reply via email to