The problem is that there can be a lot of lag between asking someone to review the PR and them actually doing it -- yes, I have definitely ran into this issue at my previous job, some PRs take forever to get merged because everyone else is so busy working on their tasks and nobody has the time to do reviews.
The process at my current job: we have a soft limit on how many tasks can be in the work-in-progress status at a time, that includes tickets that are currently being worked on, or being reviewed. Then there is a hard limit of 3 issues at a time that's test ready. When we exceed these limits, developers need to stop pulling in new tickets, and our priority becomes to help with review or test issues, that helps moving things along. Instead of assigning your issue to a specific person on the team, it is the team's responsibility to move things along and get these reviews done, that eliminates constantly bugging the same person for reviews.
Since my current job is front-end heavy, we also do preliminary QA when we're reviewing code, we pull the branch in and make sure the obvious aren't breaking. I personally find it really helpful for understanding the context of a PR and gives me a clue of what I'm trying to look for when reviewing. Of course this process is still not perfect, there can still be a lot of back and forth, and sometimes you need to ask people to explain some of the context to you. But overall I find this a fairly decent process so far, most importantly I feel like it gives everyone the sense of team work, no issue should be the responsibility of a single person.
The process at my current job: we have a soft limit on how many tasks can be in the work-in-progress status at a time, that includes tickets that are currently being worked on, or being reviewed. Then there is a hard limit of 3 issues at a time that's test ready. When we exceed these limits, developers need to stop pulling in new tickets, and our priority becomes to help with review or test issues, that helps moving things along. Instead of assigning your issue to a specific person on the team, it is the team's responsibility to move things along and get these reviews done, that eliminates constantly bugging the same person for reviews.
Since my current job is front-end heavy, we also do preliminary QA when we're reviewing code, we pull the branch in and make sure the obvious aren't breaking. I personally find it really helpful for understanding the context of a PR and gives me a clue of what I'm trying to look for when reviewing. Of course this process is still not perfect, there can still be a lot of back and forth, and sometimes you need to ask people to explain some of the context to you. But overall I find this a fairly decent process so far, most importantly I feel like it gives everyone the sense of team work, no issue should be the responsibility of a single person.