Usually, a review consists of one general summary containing the review outline plus comments that take place line by line.
Once the developer (aka student) has responded to an inline comment and the reviewer judges it sufficient, then the corresponding conversation can be marked as “resolved” to favor tidiness.
A PR is meant to be dynamic and can thus evolve continuosly as the developer adds up further commits to address reviewer’s points. New commits will be displayed and the reviewer is able to: (1) accept the PR; (2) insert single comments or better (3) request/reissue a new review made of the outline section along with inline comments, pretty much as before. This process is very common in the open-source community and runs quite seamlessly.
As a result, you’ll come up with a sort of a journal reporting the complete interaction; therefore, splitting the review in multiple PR’s doesn’t really look convenient to me.
Moreover, a PR generally goes along with a specific branches pair. Hence, supposing you’ve closed the first PR aiming to open a second one, then you ought to deal further with branching, which can make things a bit more complicated.
This is an example of a PR where conversations occured neatly because iterations have been marked as resolved (although you can still expand them by clicking on
Show resolved): https://github.com/robotology/assistive-rehab/pull/274.