• English日本語한국어
  • Log inStart now

Get early feedback with CodeStream feedback requests

New Relic CodeStream's feedback requests are powerful enough to use for traditional end-of-cycle code reviews, but at the same time they're so easy and flexible that you can use them throughout the development process to get quick feedback on work-in-progress. You can even use feedback requests for your uncommitted changes.

Traditional code review happens at the end of the development cycle, when you’re looking to get the changes merged. Not only are end-of-cycle code reviews much more burdensome on your teammates, but you run the risk of identifying issues so late in the game that you end up having to decide between blowing up your schedule or taking on technical debt.

Whether you're at the beginning of a project, with just some stubbed out functions, are mid-way through a work in progress, or are ready for a final review of a finished project, CodeStream enables feedback at any point during the development cycle. CodeStream handles the complexity of sharing your current status, including pushed commits, local commits, and staged and saved changes. Your teammates can provide feedback from their IDE, with no need to switch applications, and no need to switch branches or pull changes.

By the time you get to the formal code review/pull request at the end of the development cycle, it's far less painful and more of a formality because issues have been raised, discussed, and resolved all along the way.

For a look at using CodeStream to request feedback within an IDE, watch this short YouTube video (4:25 minutes).

Feedback request UI

New Relic CodeStream's feedback requests section lists all of the open feedback requests that have been assigned to you or that you've requested, as well as any of your recent feedback requests that have been approved or where changes have been requested.

The feedback request section divides requests by open, approved, and changes requested.

Click a feedback request to jump in and start reviewing or to see your teammate's comments on your work.

Request feedback

To request feedback:

  • Click the + Create button at the top of the CodeStream pane.
  • Select the + Request Feedback button in the header of the Feedback Requests section. If you're an admin you'll also see a gear icon to control how both feedback request assignments and approvals work for your organization.
  • You can also use a keyboard shortcut (ctlr+shift+/ r or ctrl+/ r on a Mac).

With a single click you can name the feedback request based on the last commit message, the branch name, or, if you started work by selecting a ticket, the ticket title. CodeStream assumes that you are requesting feedback on changes in the repository/branch of the file you've currently selected in your editor. If you have multiple repositories open in your IDE, you can change this via the repository dropdown at the very top of the feedback request form.

Depending on your organization's feedback request settings, CodeStream may suggest specific reviewers. Based on the commit history of the code being changed, the suggestions may even include someone that isn't yet on your CodeStream team. In that case, they'd be notified by email. Hover over a reviewer's name to see more details or to remove them. If multiple reviewers are assigned you may also have the option to determine whether any of them can approve the review or if each one has to approve it individually. Read more on how to configure the feedback settings.

Explore the files changed in the pull request

The Changed Files section lists all of the files that have been added, removed, or modified. Click any file to view a diff if you want to review your changes before submitting the feedback request.

If you have a file that's not suitable for review, such as a checked-in binary file, you can hover over any file and click the x to exclude that file from the feedback request. That file will be moved to a list below the form. New files are, by default, excluded from the feedback request, but you can hover over their entry in the list and click + to add them.

Hover over an excluded file and click the trashcan to permanently exclude it from all future feedback requests. Permanently excluding files creates a .codestreamignore file in the repository. If you think your teammates will also want to exclude these files (for example, a package-lock.json or other system-generated file), you can commit and push the file so that they can make use of it as well.

The changes represented across the selected files are broken out into four different categories, allowing you to select exactly what you would like to include in the feedback request. This includes changes that haven't been pushed, or even committed.

The four categories are:

  • Saved changes
  • Staged changes
  • Local commits
  • Pushed commits

Pull request commits

Commits are listed in descending order across the Local Commits and Pushed Commits sections. If you uncheck the box for a commit, it will automatically uncheck the boxes for all of its preceding commits. In other words, the commits included in the feedback request must be consecutive. Only your commits are checked by default, but you can include any of them in your review.


Make sure the email address in your git configuration matches your CodeStream email address. Or set up a blame map to map your git email address to you CodeStream email address.

Optionally, you can share your feedback request out to either Slack or Microsoft Teams.

When you submit your feedback request, your teammates will be notified via the activity feed, with anyone assigned as a reviewer being @mentioned so that they'll also receive an email notification.

Feedback request settings

By default, the person requesting feedback can decide how approvals work, but you can also set a default behavior for all feedback requests for your organization.

Use the feedback request settings to fine tune your organization's feedback process.

  • Any reviewer can approve, regardless of how many reviewers have been assigned.
  • All reviewers must approve individually before it's considered approved.
  • Developer who requests the review decides to approve the request.

You can also decide if and how CodeStream suggests reviewers:

  • Round-robin will cycle through all developers in the organization.
  • Random will randomly assign the feedback request to any developer in the organization.
  • The Authorship options suggest up to three reviewers based on the developers who wrote the lines of code impacted by the changes, as well as other developers who may have committed to the branch.

Provide feedback

The best part of CodeStream's feedback requests is that having your teammates look over your code doesn't put any extra burden on them. There's no need for them to set aside their own work to switch branches or pull changes and no need to for them to leave their IDE. As long as they have the appropriate repository, they can open the feedback request and start reviewing your changes.

Click any file in the Changed Files section to review the changes. The changes are presented with a diff in your editor. You can step through the changes in the file using your IDE's native navigation or click the up/down arrows at the top of your IDE. For JetBrains IDEs, CodeStream only supports the side-by-side diff viewer.

Typically, the diff will represent the changes in the branch associated with the feedback request (such as, a feature/topic branch) against the base branch, at the point at which the feature branch was created. With CodeStream diffs this may not always be the case, because the developer may not have included all of their changes in the feedback request. As a result, the version of the files that the changes are being diff’ed against may, in fact, also include changes that aren’t in the base branch. This is important in order to provide continuity.

Comments and change requests

If you have a general comment about the changes, add a reply to the feedback request's thread:

  • If you want to comment on the actual changes, select some code from the right side of the diff and then click the comment button that appears in the CodeStream pane next to your selection.
  • You can also use a keyboard shortcut (ctlr+shift+/ c or ctrl+/ c on a Mac) after selecting some code.

Since you have the full file context, you aren't limited to commenting on just the lines of code that were changed. For example, you might notice another part of the file that needs work as well or that you simply want to reference.

Whether it's a general comment or a comment on code, you can mark it as a change request to let the developer know that it's required before you'll approve the changes.

While you're providing feedback, you can even comment on files that aren't part of the changeset and they'll get added as a reply to the review. This is helpful to be able to point your teammate to another location in the codebase that might need improving.

Approve change requests

All of the change requests associated with the the feedback request are summarized in a section at the top, in addition to being part of the discussion thread. This is where they'll get marked complete when the work is done.

  • Look for the green and red buttons at the top to either approve the changes or request additional changes.
  • If there are any open change requests, the approve button will be replaced by a blue button that shows the number. You can still approve the changes, but be aware of the outstanding work.
  • When there are multiple reviewers, and an approval is required from each, CodeStream makes it very clear when there are still outstanding approvals. The blue button at the top right shows how many approvals are outstanding. The green thumbs up on the headshots of reviewers indicates that they've already approved your changes.

Add more code changes

A typical workflow involves the reviewer leaving some comments or suggesting some changes and then the developer responding to that feedback with more changes to the code. To continue the process, click the blue Amend button to add your changes.

  • Similar to when you originally submitted the feedback request, you can choose from your saved and staged changes and your local and pushed commits. Any open change requests are also listed so you can mark off any that are addressed by your update.
  • By default, when the reviewer goes back into the feedback request, they'll be looking at the complete changeset (such as, changes across all updates) as they go through the diffs for each file. They can also view the diffs for any individual update.

Approve the feedback request

The feedback review process can continue across as many updates as needed to get to the final approval of your changes. Once the feedback request has been approved, you can create a pull request from within CodeStream to get your code merged.


The feedback request can't be amended or reopened once a pull request has been created.

Copyright © 2023 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.