Sure, I think keeping track of time like you described won't be enough. At least in our case, our review policy requires the reviewer to actually download the code and see if there are any warnings, does it run as expected, etc... All this will be outside of ReviewBoard.
Perhaps another solution can be for the reviewer to "Accept" the review request, in which case a timer can be started and it doesn't stop until he/she submits the review. Hovanes Christian Hammond wrote: > This goes back to a discussion that was had in the very early days of > Review Board with one of my co-workers. He recommended actually > keeping track on the page of the time spent. It would basically work > like this: > > * On scrolling in the screenshot or diff viewer page, start a timer. > * On idling (no cursor or keyboard input) for a minute or two, pause > the timer. > * Keep the timer running while a comment dialog is up. > > This would give you roughly the amount of time spent actually looking > at code. > > We never added this because there really wasn't a compelling reason > for it, and it's some additional overhead that we didn't feel was too > necessary. > > If there's a big demand for it, and someone wants to write a patch, we > could probably include it in the codebase. Another option would be to > make this an extension down the road when we roll out extension > support (after 1.0, which should be released in December). > > Does this sound like it would work for your needs? > > Christian > > -- > Christian Hammond - [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > VMware, Inc. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to reviewboard@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~----------~----~----~----~------~----~------~--~---
