I began thinking more about this and would like to return to the topic. 
I think that a tool should help MOST people do their work right while 
being flexible at the same time. I think the ideas below are flexible 
enough that they don't stop others from using reviewboard as they were 
already, but would provide significant more value for users who chose to 
use them.

*Time - Let the reviewer estimate it*

Here is an overview of the previous discussions on this topic:

    * One idea was to keep track of time spent viewing the page. A timer
      would start on scrolling the diff viewer page or screeshot page
      and keep the timer running while the comment dialog is displayed.
    * My suggestion is to add a button that will allow reviewers to
      "Accept" a review or to have the user acknowledge that they are
      doing a review. Otherwise, RB would not let the user add any
      comments, etc...

I really think that the suggestion of having the reviewers "accept" 
would really let RB be used in many more organizations where keeping 
track of metrics is very important. This feature could be optional and 
turned off by default, but when turned on, by introducing a simple idea 
to accept the review first would allow us to gain a lot. Once we have 
this "Accept" feature, then we could integrate RB with a company's 
internal time-management/task-management system. Each user who clicks on 
"Accept" would generate a new "task" event for themselves that would be 
channeled into the company's time-tracking solution. Then, the user can 
him/herself estimate the time spent doing a particular review.
If the time-tracking mechanism is left embedded as part of RB itself 
(where RB counts the number of minutes a user spent watching the diff), 
then we are discounting the possibility that the user would ever need to 
download the changeset and try to build the product or continue the 
review off-line. I think that most GOOD source code review checklists 
should have the "Smoke Test" as the first item to check. Does the code 
build properly, are there any compiler warnings, etc... For this aspect, 
the reviewer is forced to download the changeset and try it on his/her 
machine. It would be impossible to automatically keep track of this 
significant time

Letting the user estimate the time spent doing the review is probably 
going to be the most accurate method of time-tracking. All other methods 
would be prone to huge errors.

I was told that I could do this as an extension, but given that I don't 
know what that feature is going to look like I could not comment on it. 
In any case, having the "Accept" functionality (turned off by default) 
be part of the product would not be very intrusive and it save us extra 
effort in writing an extension.

*Comment Types - Make it flexible yet provide it in the default product*

Another aspect of metrics is trying to determine the type of the 
"defect".  For instance, the reviewer could indicate that this is a 
"Performance" issue, or a "Security" issue. This would entail adding a 
"Comment Type" drop down list on the Comment dialog. I think that by 
default we could have a few common comment types, but allow the user to 
add more.

Even if we add the following 4 most default comments we would let 
companies derive significantly more meaning from their Reviewboard :

    * *General*:  This is a general comment. It may not be a bug or
      error, just a comment/suggestion.
    * *Coding Style*: This is an issue with the coding style.
    * *Functional Error*:  This issue means that the code is
      functionally wrong.
    * *Non-Functional*:  This is related to non-functional requirements
      such as Security, Performance, etc...

I was told that this could also be done as an extension but why not 
allow the users to have better review practices by gathering the right 
metrics out of the box?


hschnit wrote:
> I was also looking at ways to measure metrics. This is necessary to
> make sure that we do a good job at code reviews and it's good for
> process improvements. Without measures we have no way to know if the
> time spent reviewing code is worth the effort.
> So I second Hovanes in saying that there is a need for this kind of
> feature.
> I like your approach for measurements. They are non-intrusive for the
> users which is great.
> Additionally I was wondering if we should add a way to classify the
> type of comments (defects, coding styling, bad practice, ...). I'm not
> sure if it is possible without driving the developers and reviewers
> crazy, though :-)
> Cheers,
> -Herve

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 
For more options, visit this group at 

Reply via email to