How do I tell reviewers that I have responded to their suggestions? - azure-devops

Azure DevOps lets a reviewer tell the developer that they have completed their review with the "waiting for the author" flag on a PR review.
But as the developer how can I tell the reviewer "I have finished addressing comments?" They may get a notification for every reply I make to a review comment but typically, we work that a reviewer won't re-review until I've finished addressing all their comments. I can send them a message but it seems like there should be a way to do it from the PR itself.

Unfortenately there is no out-of-the-box method to do this.
These are the only subscription that can be made for code (git) notification:
You could however come up with a process flow yourself, some examples:
Define that all fixes should be made in one push to the branch. The developer can fix the remark in several commits, but whenever he pushes these commits the notification is send out - triggering the reviewer to look again.
Another option is the agreement of a code word or sentence in the commit message, like: rework-complete.
The reviewer filters out these message in their mail client, to see what PR are up for review again.
Alternatively you could alter the status of a PR linked work item.
For example:
After review, the develop work item is set back to the status: Active.
Whenever this work item is closed, the review can be done again.
This will avoid unwanted, out of AzDo, message sending.
Again, no out-of-the-box solution afaik, but I hope this helps you.

PR authors and reviewers can communicate with each other by adding and responding to PR comments. When you review a PR, use comments to point out issues with the proposed changes, suggest changes, and respond to previous comments. Aim for constructive feedback that's precise and easy to understand. Address recipients directly by using their #username. Reference work items by using #workitemID and other PRs by using !pullrequestID.
Reply to comments
PR authors should reply to comments to let the reviewers know how they're addressing feedback and suggestions:
To reply to a comment, type your response in the Write a reply field. Address recipients directly by using their #username. Reference work items by using #workitemID and other PRs by using !pullrequestID.
After entering your response, select Reply & resolve if your response is final. Otherwise, select Reply.
If you select Reply & resolve, the comment status will change to Resolved. PR authors can also directly change a comment's status, as described in the next section.
Change comment status
New comments initially have an Active status, which PR authors update during PR the review process to indicate how they addressed reviewer feedback and suggestions. PR authors can select a comment status from the status dropdown list:
Active: the default status for new comments.
Pending: the issue in this comment is under review and awaits something else.
Resolved: the issue in this comment is addressed.
Won't fix: the issue in this comment is noted but won't be fixed.
Closed: the discussion in this comment is closed.
When you have finished addressing comments, you can change all the comment status to Resolved and let the reviewers know that you have responded to their suggestions.
You can refer to this document Review and comment on pull requests - Azure Repos | Microsoft Learn.
If you want a feature to highlight that all comments have been addressed in the PR, it's recommended that you could submit a suggestion ticket on Visual Studio Feedback. That will allow you to directly interact with the appropriate engineering team and make it more convenient for the engineering team to collect and categorize your suggestions. By the way, you can directly add your vote after you create the suggestion ticket and keep track of this progress there. Voting helps increase the priority of the issue by consolidating customer impact under one feedback.

Related

How to batch GitHub PR post-review comments notifications?

When reviewing PR on GitHub, the is a brilliant option for reviewer
to add multiple comments as pending, and then submit them to the author as a review with one notification.
Each comment has it’s own option Reply and Resolve Conversation.
E.g. if review has 10 comments, and author wants to reply for 9 of them ‘updated in commit 12345’,
reviewer will receive notifications for each of them, which can be quite annoying.
Is it possible to make pending such post-review comments and submit them as a single notification?
If not, I will submit a feature request to GitHub.
I found existing GitHub Feature request: writing PR comments in batch #1276
and posted a workaround
The problem you described is correct if an author is using main
“conversation” tab to reply to each reviewer’s comment. As a
workaround author can switch to “Files changed” tab, and there is an
option to keep all comments as “pending” and then submit all of them
at once(simulating review of own PR)
It’s definitely not intuitive, and I would appreciate if GitHub will
implement it properly for “conversation” tab

How to get notified on Azure DevOps PR issue status change

As code reviewer with Azure DevOps you are able to leave feedback that can be marked with such statuses:
- Active: Comment is still under review.
- Pending: The issue in this comment will be addressed, but isn't fixed yet.
- Resolved: The issue brought up in this comment has been fixed.
- Won't Fix: The suggestion in the comment is noted, but won't make changes in this pull request to address it.
- Closed: Discussion for this comment is closed.
Is that possible to get notified when the status is changed? Right now I can receive notifications on new comments
We cannot get this notification, In the Azure DevOps default and supported notifications and supported event types have Changed by, Changes in folder, Code under review, Created by, Event type, Policy Bypass, Repository name, Reviewers, Source branch name, Status, Target branch name, Team project, Vote. And the comment will only Notify you about comments made to a pull request that you created or a discussion you're involved in.
This should be a good improvement, also I have helped you to submit the relevant suggestion ticket. To receive the notification about it in time, you can vote and follow this suggestion ticket.

How can I review comment history on Azure DevOps Pull Requests?

I have noticed that when you modify a comment in a Pull Request, there doesn't seem to be a way to view the history of the comment. As well, comments still allow editing after someone responds to it. One of my colleges is editing comments after he gets a response and our pull requests are not making sense because of it. Is there a history or a way to prevent changes?
Sorry but as I know it's impossible. Besides, similar issue has been submitted in this earlier suggestion ticket linked here:
Disable comment editing (i.e. add, edit, delete, and state change) in completed pull request
In addition, we can use below API to get Pull Request Thread Comments to check lastUpdatedDate and publishedDate.
GET https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/threads/{threadId}/comments/{commentId}?api-version=5.1

On GitHub, what's the difference between reviewer and assignee?

A feature added on Dec, 7, 2016, announced on GitHub blog, introduced the option to add reviewers to a Pull Request
You can now request a review explicitly from collaborators, making it easier to specify who you'd like to review your pull request.
You can also see a list of people who you are awaiting review from in the pull request page sidebar, as well as the status of reviews from those who have already left them.
However, explicit setting a reviewer for a PR was already done by assigning people (assignees option).
With both options now available, what's the role of each option since they both share the same end goal?
EDIT:
After discussing with several OSS maintainers, reviewers is defined as what the word supposed to be: to review (someone's code) and "assignee" has a looser definiton explained below.
For "reviewer": someone you want to review the code. Not necessarily the person responsible for that area or responsible for merging the commit. Can be someone who worked on that chunk of code before, as GitHub auto-suggests.
For "assignee": up to the project's team/maintainer what it means and there's no strict definition. It can be the PR opener, or someone responsible for that area (who is going to accept the PR after the review is done or just close it). It's not up to GitHub to define what it is leaving it open for project maintainers what fits best for their project.
Previous answer:
Ok I'll go ahead and answer my own question.
For PR of users with write-access: the Assignee would be the same person who opened the PR, and reviewer would replace the old assignee function (reviewing code), being this one someone of assignee choice.
For PR of users without write-access (outside contributors): Someone with write-access would assign herself (or other write-priviledge member), to review the PR (Reviewer). Assignee is blank.
For unfinished PR from outside contributors: the write-access member would take the unfinished work and assign for her. She will be responsible for finishing the task, being the Assignee. Since the main reason of PRs is reviewing changes, she would select some other people to review the changes.
In GitHub a reviewer is a person who reviews the pull request. A project owner can request review from any of the maintainers, They can even set an option so that the pull request can be merged only if it is reviewed by one of the maintainer with write access.
According to official github documentation, Assignee is a person who is working on specific issues and pull requests. It is sometimes confused as a reviewer. It is actually meant to be used with issues rather than pull request so that when we receive a issue we can assign someone to fix it. In a pull request, an assignee refers to a person who's in charge of merging that pull request after getting comments and change requests from other maintainers.
As per accepted answer. Yes, "assignee" has a looser definition and can be used differently to suit a teams need.
In our team of 8 devs, in most PRs we have 1 reviewer, who suggests changes and ultimately approves the PR. During review phase, "assignee" is the person who opened the PR; later on if PR is picked up by other developer, a new "assignee" is added. Once PR is approved and ready for QA or direct merge, a new QA "assignee" is added. This way "assignee" list grows.
We use "assignee" to designate following people collectively:
Pull Request Author
Author working on PR change suggestions (usually same as 1)
QA person involved
Person responsible to merge (usually same as 2 or 3)
Using "assignee" helps locating the PR in future easily. One of my project has >3000 PRs.
is:open is:pr author:raya-dumas
is:closed is:pr assignee:raya-dumas
Or just author:raya-dumas to find all items author created (issues, PRs)
and other similar queries to ease the search process. "milestones" are quite helpful to use as well to ease PR search.
The biggest difference between "reviewers" and "assignees" is that reviewers actually have a tracked state according to GitHub -- did they review the PR yet or not?
When you add a reviewer, what it actually does is create a "review request":
The reviewer gets notified (like an "assignee" would) but now they actually have a task they can complete, which is to provide a "review" on a pull request:
After the reviewer leaves a review (approving or requesting changes), that information is tracked in the GitHub API and interface:
With assignees, you can associate people with a PR but beyond that GitHub doesn't really care what that means or what those people need to do. With reviewers, you can use new search queries, "protect" branches, assign reviewers with CODEOWNERS, and build deeper API integrations around review assignment and workflows manually or through tools like PullApprove.
Before GitHub only had an assignee field and no reviewer field. There was no distinction back then so the assignee field was most commonly used as a reviewer field.
But use them whatever way suits your project.
Another difference: the person who created the PR can assign himself/herself as the assignee, however cannot request himself/herself as one of the reviewers.

Github notifications - Mail to PR creator

If I raise a Pull request and if I need to be notified by a mail saying --
You have created a Pull request for "bla bla" on "so and so" date.
On merge - I get a notification
On comment - I get a notification
So my question is...
Are there any such settings in github which sends a mail to PR creator?
Can I tag myself in the PR comment ?
Any help !!
Are there any such settings in github which sends a mail to PR creator?
There's currently no setting in GitHub that makes the platform work in that way. Note: You can send an email to support#github.com to request for such a feature.
Can I tag myself in the PR comment ?
Yes, you can. But that won't trigger an email sent to your mailbox
However, if what you're after is keeping track of your own activity on GitHub, there may exist another alternative: GitHub exposes atoms feeds for various endpoints. The user is one of them. Register your own feed in a RSS reader and you're done.
Syntax: https://github.com/{:user}.atom
Sample: https://github.com/mojombo.atom
I'm surprised that despite being up for so long, this question hasn't really been meaningfully addressed. Axibase designed a cool little tool which can do exactly what you're describing here: if a PR is raised in one of your repositories you'll be notified via email or third-party messenger service.
By default the rule will fire when anyone raises a PR, but it can be configured to only respond to specific users as that seems to be one of your requests.
The workflow here describes the underlying mechanics of the tool and this guide will take you through the entire set-up. The whole process should only take about 10 minutes from start to finish.
Disclaimer: I've worked for the team that develops ATSD, which is the database at work here.