logo

Why I assign myself to my own pull requests

The assignee field answers a different question than the reviewer field

Joel Clermont
Joel Clermont
2026-07-06

When Aaron and I open a pull request, we assign a reviewer. That's pretty obvious, and most teams we work with do that.

But we also always make it a habit to assign ourselves to the PR, and for some reason, some teams resist that last step.

The pushback is usually the same, and it is fair. "I opened it, so don't I already get notified when something changes?"

Yes, you do. GitHub automatically subscribes you to any pull request you open, so you will hear about every new commit, comment, and review whether your name is in the assignee box or not (though I don't think this was always the case).

So why do we bother with adding ourselves as the assignee? Because the assignee field is answering a different question than the reviewer field.

The reviewer field says who should look at this, but the assignee field says whose work this is.

Depending on your workflow, this can also affect what happens after the review.

Does the reviewer merge it automatically?

If not, someone still has to potentially tidy things up based on non-blocking feedback, resolve a merge conflict that showed up overnight, and finally decide when to click merge, likely triggering a deployment.

It's extremely unlikely the code reviewer is ready to take all that on, so I like to have it assigned to the original person. That way it shows up on their task list to complete, and it is absolutely clear who owns this code.

Here to help,

Joel

P.S. Want to work with us and get your team processes optimized?

Toss a coin in the jar if you found this helpful.
Want a tip like this in your inbox every weekday? Sign up below 👇🏼
email
No spam. Only real-world advice.