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

Question

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?

Sickener

when "assignee feature" release the first time? Is there any article that introduces it? – Phelgen

Answer 1

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.

Sickener

For every new team member I should send a link to this answer to explain how to deal with assignees and reviewers. Which leads me to the thought that something is fundamentally wrong here :( – Superpower

Does an assignee have to have write access? – Apophyge

is there a difference in email notification behavior between the two? – Abie

Email notifications are similar, but one says you were "assigned" and the other says that someone "requested your review". The emails also have different "to" fields (ex. to:[email protected]) which you can use to create a filter in Gmail that automatically applies a label, for example. – Bucharest

Answer 2

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.

Propst

Thanks for the answer, but I don't think it addresses the question fully. You can assign an issue to someone (so she will be the issue assignee), but when the PR is sent someone would be the reviewer (PR assignee), and at this point, I'm still not clear about the difference between assignee and reviewer. – Sickener

Answer 3

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:

1. Pull Request Author
2. Author working on PR change suggestions (usually same as 1)
3. QA person involved
4. 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.

Disease

Very well explained. – Smelly

It should be mentioned that you can just search for author:my-github-handle to find what PR's a person created – Rossuck

But why not add the QA engineer in the reviewers, since they are reviewing the PR AND it will notify them of the fact? – Instrumentality

Answer 4

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.

Bucharest

Answer 5

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.

Flicker

Answer 6

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.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review

Assignees clarify who is working on specific issues and pull requests.

https://docs.github.com/en/issues/tracking-your-work-with-issues/assigning-issues-and-pull-requests-to-other-github-users

---

_{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.}

Freemason

Answer 7

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.

Nonresistant