Thanks - that does clear it up quite a bit.
Yes, I might open a review request to see the new comments but, before
responding, have to do something else. At that point, I really need to
know that I need to get back to it. Maybe I could just use the star.
Yes, the question I'm trying to answer is who's ballpark it's in. I
think our scenario is similar to what you've described. After the diff
is updated, I see the review in my incoming list. Then I make
comments, and the submitter sees that there's a comment bubble icon.
Then we might iterate over the initial set of comments, discussing
each issue. So the submitter responds (to my -- the review --
comments), and then I see they've responded because the review shows
up in my list with the comment bubble icon.
I guess my only point is that the comment bubble icon isn't enough.
Simply because if I open the review it goes away. I'd rather the
review appear in my incoming queue until I respond with comments and
publish. Conversely, if I'm the submitter and the reviewer comments on
my request, I want it to show up in my incoming queue. Then when I
respond and publish, it goes back into my outgoing queue (and into the
reviewer's incoming queue).
I think the comment bubble icon will get the job done. I'll just make
sure to allocate enough time to finish dealing with a review request
any time I open it up.
On Thu, Jun 9, 2011 at 3:38 AM, Christian Hammond <chip...@chipx86.com> wrote:
> Hi Jeb,
> Jan had some good comments, and I'll add a bit to that.
> The New Comments icon does indeed go away when you open the review request.
> The intent is that you'll read whatever changed when you next view that
> review request. I'm guessing in your workflow, you sometimes go into a
> review request to make updates but then want to see any comments since you
> last read it?
> In the upcoming 1.6 release, we collapse all reviews that are older than
> when you last visited the review request, making it easier to see what on
> the page you really should be paying attention to.
> I think down the road, we can do better about actually tracking whether
> you've viewed a review, based on where you've scrolled. Not in 1.6, but
> perhaps after.
> It sounds like what you're wanting though is really a more clear "Who's
> ballpark is this in?" This sort of workflow is very specific to individual
> setups, so I'd be hesitant to bake it into Review Board itself. However,
> that can be where extensions come in. In 2.0 (which we'll be working on
> after 1.6 is out the door), we'll support writing custom extensions that can
> augment the dashboard and review requests, amongst other things, and it's
> conceivable that someone would write such an extension.
> What I'm curious about though is how you decide when it's the reviewers'
> turn and when it's the developer's turn. It seems that it's generally the
> reviewers' turn when a new diff is updated, and the developer's turn any
> time after there's any feedback. How would you change it in your setup?
> Christian Hammond - chip...@chipx86.com
> Review Board - http://www.reviewboard.org
> VMware, Inc. - http://www.vmware.com
> On Wed, Jun 8, 2011 at 2:35 PM, Jeb <jebbe...@gmail.com> wrote:
>> I've read the docs and looked out on the web and haven't really found
>> enough on this subject to satisfy me. Using RB seems pretty simple.
>> Someone creates a review request. I review it. We iterate over the
>> review, having these nice threaded discussions. Code is changed or
>> not, finally it is submitted and closed. The tough part for me is
>> knowing exactly when I've got work to do.
>> 1. Bob creates a review
>> 2. I respond to it asking for clarification on a few things
>> 3. Bob responds
>> How do I know Bob responded?
>> Email - that's not enough for me, I don't rely on email to keep track
>> of workflow issues like that
>> New Comments Icon - what happens when I click the review and then mess
>> with it -- that icon is gone and now it looks like any other review
>> I just wish I could have some custom status or something where I could
>> do the review, hit publish, then change it to "awaiting coder
>> feedback" or something and have it show up in the submitter's incoming
>> I'm sure I'm missing something, and I apologize for wasting anyone's
>> time with this, but I could really use some help.
>> Want to help the Review Board project? Donate today at
>> Happy user? Let us know at http://www.reviewboard.org/users/
>> To unsubscribe from this group, send email to
>> For more options, visit this group at
> Want to help the Review Board project? Donate today at
> Happy user? Let us know at http://www.reviewboard.org/users/
> To unsubscribe from this group, send email to
> For more options, visit this group at
Want to help the Review Board project? Donate today at
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to
For more options, visit this group at