|
IdeasFor2_0
Ideas for the Review Board 2.0 release
IntroductionThis is a dumping ground for ideas we'd like to see in Review Board 2.0. Some features are definitely planned while some are just possibilities. Hooks and ExtensionsOne of the big features of 2.0 will be support for hooks and extensions. Hooks are simple scripts that are invoked under certain operations (posting a new review request, or a new review). Extensions are pluggable components that users can install that will provide additional functionality to the product. These might provide new UI (for example, additional fields in the review request details box, a new section of the UI for custom data, or even a whole new front-end). The plan is to turn the current iPhone UI into an extension. We might even make the Reports view an extension as well. We may decide not to implement a separate concept for hooks and instead just use extensions, so that they can be managed easier. If done correctly, extensions will be really simple to write. Feature requests tagged with Extensions are candidates for future extensions. New Reviewable File TypesThere has been some request for reviewing files other than diffs. Screenshots have been the main one, though someone suggested Wiki changes and specialized views for certain text documents. It would be nice to make our current comment setup a bit more generalized and allow new models provided by extensions to associate a comment with their own data. These comments would be part of the review, and would have the extension render the necessary comments in the review. The extension would also be responsible for providing the whole review UI for this file type. This would need some help from post-review, as binary files are not included in diffs. We would have to manually upload some files. Perhaps we can expose a list of supported mimetypes and file extensions for review, accessible through the API, and have post-review query that when deciding what to include in the diff. Review Request Update NotificationsIt would be handy to know if someone has posted an update to a review request that you're currently on. We could pop up a little notification in the corner, similar to what GMail does for new conversations, informing the user that the review request has updated. There would be "Update Page" and "Ignore" links. Moved Regions in DiffsOne feature I've been wanting to work on for a while is for our diff generator to be smarter about when code moves. Instead of marking this up as inserts/deletes, we can mark it as a "move" and indicate where it moved to. The diff viewer could then format this differently. This would give users a good visual cue that the code was only moved, not modified. We could go further in this by marking up moved regions even when part of the region changed, and then show those changes as well. This would require that we have some kind of threshold for number of changes (and how extensive those changes are) within a region of moved lines. It would be tricky and maybe we only care about the first part for now. Improved Auto-CompleteOur current auto-complete is nice, but one easy way to improve it is to allow for showing the full names/group display names alongside the IDs, and to also search full names and group display names when typing. That way, you could type either "chipx86" or "Christian" to find the right person. CIA SupportCIA is a tool developed to keep track of commits to code repositories. These commits are often relayed to project IRC channels. Some projects use it for their issue trackers. We could use it to notify when there are new review requests or reviews, giving people in project channels instant notification and a URL. This would be an extension and not built into the codebase. Attach Arbitrary FilesSome users have requested that we allow for attaching any file type to a review request. This would be useful but of course could be open to abuse. Along with this feature we would want to provide a configurable max file size, maybe even configurable mimetypes. And of course administrators should be able to disable this feature. Attach Arbitrary LinksLikewise, it may be useful to have a list of links associated with a review request (such as a specialized diff for users that haven't seen the light yet). This would be fairly easy to add if we decided to do it. |
Sign in to add a comment
I'd love to see some checkboxes for a comment. Something along the lines of 'Must fix', 'Should fix', 'Optional', with tracking of this to ensure all the 'Must fix' items are completed before the review is considered complete.
Id also like to see support for things like showing file mode changes (git tracks the exe file mode bit). I guess it would be file attribute changes along side a diff
Being able to tag or 'bundle' reviews would be good. It might be handy for other custom extensions tackling deployment or packaging.
I'd like to see review priorities and a way to bug the reviewers to remind them of outstanding reviews. It would also be nice to have Mandatory, Optional, and Just Looking reviewers.
I'd like to see the ability for each user to be able to select their repository password instead of one global password. We currently use perforce and each user has a perforce account with username and password.
Would be great to see size of a diff at a glance from the review list page (# lines in change) and in the notification email.
Simplify Windows installation.
I'd love to see an XMLRPC interface in addition to the JSON one.
Attaching more than one diff to a Review Request would be great. It kind of ruins the model you get when you associate a RR to a Diff (which is an intuitive model), but I ran into an issue with it.
For example, we have separate repository locations for our media (CSS and image) and for one of our projects. This meant that I had to make two separate Review Requests - one for the code and the other for the media - because each diff had a different base path.
Perhaps it's a limitation with Subversion's patch creation tool for Eclipse (not being able to explicitly define a change's absolute path in the repository), but take that as you will.
What about support for metrics?
What about an easy way to tell which issues in a review has been addressed? A way to see that submitters have agreed that the issue has been addressed and a way to see that the code is complete (all issues addressed)?
please add the ability to comment on a RR via e-mail and have it show up in the web interface (i.e. ingoing e-mail support). some people are married to their e-mail client :)
otherwise, great app!
This is to second elvstone's suggestion: "please add the ability to comment on a RR via e-mail and have it show up in the web interface (i.e. ingoing e-mail support). some people are married to their e-mail client."
Whether or not people are married to their email client, it is all too easy to just respond to the email, rather than go to the web to respond. The net effect is that the response doesn't get onto the web, and can easily be lost when the time comes to create the final code revision.
At some point the number of reviews becomes quite large. It is difficult to sort them out or find the one of interest. Will it be possible to ad folders to the dashboard? In this case users can sort the reviews int different topics or subprojects.
Will it be possible to add "an observer" option? Right now I can only add people who have to review the code. However, it would also be nice to add someone else who can observe the change but doesn't have to review it. This person will get all the e-mail notices.