Once a ticket is ready to be reviewed by the Reporter (e.g. project manager, etc), the developer will change the Status to "Ready for Review", but keep the Assignee to himself/herself...At this point it time, should the ticket Assignee change to reflect the person that has to act on it next?
There is no universally-correct answer to this question. However, in my experience there are two common workflows to consider: ticket-owner and task-performer. Which one will work best for you will depend on your organizational structure, team culture, and the project's communications plan.
"Ticket Owner" Workflow
This workflow is based on the idea that a ticket has an owner who is responsible for shepherding it through your process. JIRA is somewhat limited in its ability to reflect collective or collaborative ownership of tickets. While it's technically feasible (albeit inconvenient) to assign tickets to a group, none of my enterprise clients ever do this.
Instead, the ticket owner will often use the mention features in ticket comments to engage specific task performers. For example, if the ticket is assigned to Bob, he might change the status to "Ready for Review" and then add a comment to the ticket like the following:
[@alice] Please review feature foo by Friday, and let me know if solves the embiggening issue described in the ticket.
This will notify Alice that she has something to do, and she can likewise reply in the comments as well when the review is done, or when she needs help or clarification. This fosters communication and collaboration, despite the assignee field itself not being a particularly agile way to denote team (rather than individual) ownership.
"Task Performer" Workflows
Task performer workflows are composed of either hand-offs or subtasks. These are less agile workflows, in my opinion, but they can work well when the goal is to monitor or track who is doing what, rather than focusing on collaboration. The main downside to both of these approaches is the reliance on push queues rather than pull queues, which makes it harder to manage work-in-progress limits or accurately estimate workloads in advance.
In this workflow, work is handed off to other people by explicitly assigning them to the ticket. For example, once Bob has embiggened the widget, he can then assign the ticket to Alice to for review. When Alice is done with her review, she can assign the task back to Bob, or to whoever is responsible for the next step in the ticket.
Instead of changing the person assigned to a ticket, a task or story owner may create subtasks and assign them to specific task performers. However, this workflow is less flexible than either mentions or assignee hand-offs because you can't create subtasks of subtasks in JIRA, and the additional task management creates additional process overhead that can quickly swamp small or fast-moving tasks. Also, the very act of assigning subtasks to people rather than collaborating with them is a project smell that whiffs of command-and-control rather than agility.
On the other hand, the subtask workflow has a few benefits within JIRA. Individual steps become trackable as first-class items on the Kanban board, and it can help decompose larger tickets into items which are either done or not-done in a more visible way.