This page describes GHC's conventions for handling merge requests and code review.
Title: GitLab maintains a convention where MRs whose title begins with WIP: are marked as work-in-progress. This marker is understood to mean that review is not yet required. Perhaps a contributor will offer a review regardless, and contributors of WIP patches can request reviews from individuals. But if you mark your patch as WIP and it gets no reviews, that is why.
Milestone: The first release which should contain the merge request (or a backported version of it)
Labels: This encodes a number of things including:
Has the head.hackage job been run to characterise the effect of the change on user code?
Changelog and release notes entries are mandatory
Have package versions been bumped as appropriate?
Has an entry been added to the next release's migration guide?
After a patch has made it to master it might be appropriate to backport it to the stable branch (e.g. ghc-8.8). If backporting is desired first ensure that the issue is milestoned for the next minor release and mark the merge request containing the fix with the backport needed label.
While the release manager can perform the backport on your behalf, it is appreciated if you open a merge request with the backported patches yourself. There are two ways to backport a merge request:
Via the web interface using the "Cherry-pick" button on the merged MR. While convenient, this is only possible if there are no merge conflicts with the stable branch. Be sure to select the correct target branch.
Via the command-line using the git cherry-pick command. In this case select the appropriate "backport" template (e.g. backport-for-ghc-8.8) when creating your merge request.
After the merge request is created ensure it has the backport label applied and that its milestone is set appropriately.
Once the backport MR lands the backport needed label can be removed from the source MR.