Reputation: 9892
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?
Upvotes: 391
Views: 181172
Reputation: 9892
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 definition explained below.
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.
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.
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-privilege 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.
Upvotes: 286
Reputation: 1087
A reviewer is someone you've asked to review the changes you've proposed in a pull request.
An assignee is someone who is working on a pull request.
From the GitHub documentation:
After you create a pull request, you can ask a specific person to review the changes you've proposed.
Assignees clarify who is working on specific issues and pull requests.
What does it mean to work on a pull request? Obviously coding counts, but should reviewing be considered work as well? I've seen people use assignees to mean required reviewers, while the others listed under reviewers are optional. This does require adding required reviewers to both assignees and reviewers though.
Upvotes: 3
Reputation: 5222
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.
Upvotes: 3
Reputation: 3339
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.
Upvotes: 13
Reputation: 1717
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.
Upvotes: 4
Reputation: 8140
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:
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.
Upvotes: 48
Reputation: 2655
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.
Upvotes: 55