The client would like the ability to export a printable copy of any code review. This could be provided to auditors who otherwise do not have access to the online code review tool, or attached as supporting evidence in issue-tracking systems that cannot link to the online code review tool. (It would also allow reviews to be conveniently uploaded to Gradescope, hint hint...)

The printed version should contain the entire review history, including code patches for each revision, reviewer comments and approvals, and the status of automated checks. HTML output (as a single long page) would be sufficient, but direct export to a PDF file would be nice too.

The user should be able to configure several aspects of the output format, including whether patches are relative to the previous revision, whether comments attached to lines of code are shown inline or collected separately, and whether some revisions or files/directories should be filtered out.

Some reviews (such as those for automated refactoring) may consist of very large patches that would be expensive to render. The feature should warn the user in such situations (before hanging the server or their browser) and offer options for filtering the output.

This capability may interact with the “multi-anchored comments” project.

Reviewers can add comments attached to a specific line of code. However, many kinds of comments apply to multiple lines of code (for example, they may suggest moving a line from one place to another, or they may spot the same defect in multiple files). The client would like users to be able to “link” a single comment to multiple locations in files in the review. This will reduce redundancy for authors responding to feedback without reducing thoroughness.

When adding a new inline comment, the user should have the option to link to an existing comment in the review (possibly constrained to the same patchset/revision). When browsing comments, they should list and hyperlink to all file locations that link to them.

It would also be nice if comments could reference a range of lines in a file rather than just a single line (this is already supported by Review Board).

This capability may interact with the “paper trail” and “comment on untouched files” projects.

One of the trickiest parts of reviewing code is identifying changes that are necessary but absent from the submitted patch. Or sometimes it would be convenient to reference a pattern or bit of documentation that appears elsewhere in the codebase. Unfortunately, many code-review tools limit comments to files and lines that were affected by the patch. The client would like the ability to attach comments to other, currently unaffected lines and files.

The first step is to support comments on files that are affected by the changeset under review, but attached to lines far away from those affected by the patch (this may already be supported by some code review tools). Next, users should have the ability to introduce additional files to the review (with zero changes) for the purpose of commenting on them. Given the number of files present in many codebases, the user interface for selecting the file deserves special attention.

The review interface should clearly distinguish files that have no changes in a particular revision and are only referenced by comments. And when viewing such files (or viewing comments in changed files far away from the changes), the interface should show some context around the comment(s), then “collapse” other code in the file, as it does between changed regions.

This capability may interact with the “multi-anchored comments” project.

The client would like reviewers to have the ability to mark individual files (or even regions of files) as “read” at a particular revision of the review. This helps them keep track of changes they have already looked over.

If a subsequent revision does not change a file that was marked as “read,” then that file should be shown as “tentatively read” in the new revision (if the file was changed, it should be marked as “unread”). The reviewer can change the status to “read” or “unread” (or back to “tentatively read”, if applicable) at any time. The history of all changes to a file’s read status (at a particular revision) should be recorded, and there should be a way to view that history in the UI.

The review interface should show the user what proportion of the code under review they have read (and tentatively read) at each revision. If read markers are supported for regions within a file, then the file’s overall read status should be shown as a percentage.

Read status should be stored separately for each reviewer. By default, a reviewer should only see their own read markers, but there should be a way to view other reviewers’ read status as well.

The client would like reviewers to be able to propose their own small changes to code under review (such as fixing minor typos or rewording a comment). The author would then have the ability to approve these suggestions, resulting in a new revision with the changes applied. In a merge-based review, this could create a new commit.

An additional desired feature is an interface for approving suggested changes as a batch, creating only a single new revision (and allowing the author to customize the commit message for a merge-based review).

The user interface needs to be very streamlined – it should be quicker to make small changes using this feature than for the author to upload changes made in their editor in response to a comment.

(Only applies to Review Board; Gerrit already has this feature.)

The client would like reviewers to be able to attach comments to lines of text in a commit message. For a merge-based review, they should be able to comment on any of the commit messages.