Hi Darren, Thanks for this write-up! It helps us to know where we can improve in future versions.
Some comments inline. On Wed, Apr 15, 2009 at 9:56 PM, Darren <spaces...@gmail.com> wrote: > "The Dashboard doesn't keep track of reviews that you have completed. > Instead it shows all the reviews in a large list. It's quite difficult > to know if you have completed a review or not by just looking at the > list. I believe it just colorizes the Posted and Last Updated columns, > but I believe this doesn't directly indicate the status of the review, > and doesn't indicate which reviewers haven't completed. It's probably > just triggered by time from when the review was created." If you click the "..." button to the right of the columns, you should see a drop-down list of possible columns you can add. One of them shows whether you have commented on the review request, and will show a green comment flag for pending draft comments, a blue one for published comments, and a blue one with a checkmark if you marked "Ship It!" There's other columns for the number of reviews, one showing whether anyone's marked Ship It on the review request before, one showing whether there were changes since you last saw it, etc. The "..." button isn't as noticeable as it could be. We'll probably look into ways to improve this in the future. > "Comments are hard to follow. I find that the way the list of comments > gets rendered that it's hard to follow. I realize they're sequential, > but I just find it confusing at times." Can you go into more detail on this one? What was expected? "Having to click publish is a bit of a clunky workflow. Sometimes I > forget that the green strip is there with a publish on it. I just want > to say OK to a comment and have it publish. Having to click publish is > an extra step I feel the tool could do without." This step is due to the e-mail functionality. One of the goals when we initially developed this was to better integrate into workflows where people would check their e-mail to read review requests. This was common at VMware (where I work) and in many open source projects. Review Board had to know when to send the e-mail. We decided the best time would be when the user actually finishes the review request. We also wanted to make sure we didn't publish comments too early. There are many times where I've made comments suggesting changes that I realized were a bad idea or already done when reading more of the diff. If these were auto-published, users would see them and waste time with an unneeded explanation. I don't know how we'd be able to get rid of the publish step without adding confusion and breaking e-mail notifications (and, in the future, other notification types that need to know when a review is complete). "There's no indication as to who has completed the review, and who has > yet to complete it. This would be helpful" There's been a lot of demand for this. A lot of this requires company-dependent policy. Different companies have different requirements for who should review a review request. There may be a group of senior engineers that must sign off on it, or they may require 50% of the people on the target reviewer list, or 3+ people, etc. We're going to be working on coming up with a policy model that would allow for the flexibility needed to describe this after 1.0. Then we could have some UI that shows who still needs to review and who has reviewed. "It can't roll up revisions. Though this is because this tool is for > pre-checkins, it still makes it harder for the review to stay relevant > once you have made some further changes. You would have to start > another review with the new patch file, and that just makes the review > dashboard messier than it already is." I'm probably confused as to what you mean here. You can upload new diffs to an existing review request. Just click "Update Diff" in the top-right of a review request. The post-review tool (part of RBTools) makes this really easy (and makes posting review requests themselves really easy). Some companies even have post-commit hooks that use post-review to do the work for you, though this is pretty dependent on the company. We'll continue to watch ReviewBoard closely -- it seems like it's on > its way to being a solid tool. Thanks. Hope some of my answers above helped clarify a couple of things. There's a lot of good code review tools starting to spring up, which is a great thing. Review Board started as a small project to scratch an itch, and wasn't originally intended to compete against "the big guys" in this sector. It's not going to be for everybody, but it's always nice to hear good feedback and good criticism :) Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.review-board.org VMware, Inc. - http://www.vmware.com --~--~---------~--~----~------------~-------~--~----~ 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 reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~----------~----~----~----~------~----~------~--~---
