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? Hovanes 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 email@example.com 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 -~----------~----~----~----~------~----~------~--~---