This is how the network team uses Gitlab to do code reviews.
### Marking something for review
When you write code that you need reviewed, you create a Gitlab Merge Request and a Github Pull Request (for CI to work until we get GL CI). Within that MR, you reference the GH PR. Then you are done.
### Assigning reviews
When asn and David assign reviews for little-t-tor we check for unassigned GL Merge requests in the components of little-t-tor, chutney and sbws. When we want to assign a merge request to Alice, we change the "Assigned" field of the MR to Alice.
When you do your reviews, the happy path is that the patch was good and
you merge it, close the MR and the gitlab issue.
#### Reviewing your reviews (sad path)
If the patch you are reviewing needs revisions, you need to change the Assignee of the MR back to the patch author. This signals to the patch author that revisions need to be done (plus also adds it into their TODO list)
#### Revising your branches
If a branch needs to get revised, the author revises it, pushes the revised branch, and switches the Assignee field back to the reviewier (effectively also adding it to the reviewer's TODO list).