Thanks for this write-up! It helps us to know where we can improve in future
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
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 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
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to
For more options, visit this group at