Review Board Issue Tracking: A Sneak Peek

So I wrote my (hopefully) last mid-term ever last night, and in celebration, I thought I’d put together a little video showing off the issue tracking feature I’m hoping to put into Review Board.

It’s still in it’s very early stages.  The code hasn’t been reviewed.  I’m still really really open to suggestions and feedback on this.  So please, comment here, or on the reviewboard-dev list.

So here it is – enjoy!

(Click here if you can’t see the video)

11 thoughts on “Review Board Issue Tracking: A Sneak Peek

  1. Ari

    not a review board expert but is there a way to clearly see the context of each code change (especially for changes that were made only to one line), as currenly it only shows the specific diff but it’s hard to review something out of context

    is there a way to see a list of all bugs in the code review in one list? (this might be part of a reporting module as well)
    is it possible to distinguish comments from bugs by giving bugs/issues a different background color (red for example)?

  2. Ian Battersby

    Hi Mike,

    Great effort, I really like the concept and can testify we’d start using the feature tomorrow. My only comments would be that I think the scope of this needs to be extended and more intrinsic to the product. Simply I can see few times I wouldn’t mark something as an issue, as knowing it’s been resolved and perhaps allowing them to enter comments as to how/why would be key to our work-flow. I’m reminded of the defect tracking feature that Code Collaborator has, is this something on the RB radar?

    Hope that helps 🙂


  3. Mike


    Review Board shows you the added/changed/removed lines for a particular file, but the surrounding code is collapsed to save on vertical screen real-estate. There is a link in the diff-viewer to expand those collapsed portions to see the bigger context of the changes.

    Yes, a list of all of the issues in a review request is a good idea. Thanks!

    And also, distinguishing comments based on whether or not they have issues attached – another great idea! Thank you!


    Agreed – a column to display the number of raised, open, fixed, and dropped issues would be a great idea. Thanks!


    I hear what you’re saying. The thing is, workflow and the requirements (and terminology) are different from project to project.

    I should have emphasized this in the blog-post: what we’re starting with is the absolute bare-minimum. The idea is that we want to make issue-tracking *extendable* using the upcoming RB extension framework, so that users can do things like have different classes of issues (bug, typo, question, etc), add additional info to issues, and other more project-specific behaviours.

    So to summarize: I think what you’re asking for will be possible in the near future. Just be patient while we lay the foundation groundwork, and then we’ll go from there. 🙂

    Thanks for posting, all! Let me know if you have more ideas.


  4. mxbraun

    Very nice start.

    In the interest of saving clicks, I think it would be useful to have “Automatically open an issue” be a configuration option. For most reviews on our projects, comments result in issues. Since not all projects may be this way, it would be useful to do this.

    Also, fixing an issue without comment is unambiguous and fine, but IMHO dropping without comment will likely lead to the followup discussion, “Why did you drop this?” It would be a good enhancement (again, maybe configurable) to require a comment for issue “droppage”.

    So, can a review be marked “Ship it” if there are still unresolved issues?

  5. Tara

    I’m loving this, Mike! Then again, my Review Board at work is hardly (read: never) updated, so even when you get this in, I probably wouldn’t see it for a few years.

    I like how simple it is. I do almost the exact same thing – when I’m going through a code review, I respond to every comment as either “DONE” or with some response. So having them be issues would be really useful since checkmarks are a much more visual way of seeing that.

    P.S. I just noticed that I’m on your blogroll, thanks! You’re on mine too – I just haven’t decided if I will publish the whole thing yet publicly. Eventually, I’ll make a decision on that one and I’ll probably end up publishing a subset.

  6. Mike


    Re: “automatically open an issue” – that’s a good idea. We might want to make that a per-user option. Or maybe a key/click combo, like – if I click and drag some lines of code, it assumes an issue is opened. But if I click and drag some lines of code while pressing CTL or Shift, no issue is opened. Although that might be making it too complicated.

    Re: “require a comment for issue ‘droppage'” – yeah, that starts to get into the murky waters, where each project might have their own policy on this. Some might want to enforce it with the tool. Others might just enforce it socially. It’s a good idea – I’ve jotted it down. Thank you. 🙂

    Currently, yes, a review can be marked “ship it” with unresolved issues. This, like the last point, might become a configuration option.


    Thanks! I didn’t know they were using RB at your work. That’s cool! Which version? Glad to hear you’re doing code review, though. And it’s always great to see you get in on the MarkUs reviews.

    Simple is the key, here. Simple, and stripped down. Then we can get all crazy using extensions and whatnot, and people can roll their own poison. I think it’s a matter of finding/distilling the very very basic elements that all people want, and working up from there.

    Thanks for posting, both of you!


  7. rajgui

    Hi Mike Conley

    I am trying Review Board. Can you please upload a patch or something so that we can use this feature of OPENING AN ISSUE feature.Its really cool.
    thanks in advance

  8. sreedevi

    Our requirements are:
    1. Always (mostly) create an issue. Is it possible to enable “Open an issue” by default OR always create an issue?
    2. Branch field a drop down. Is it possible to make this a drop down?

Comments are closed.