GitLab/Workflows/Code review

Code review is an essential part of our contribution workflow. The principle is basic: any patch must be reviewed by others before being merged. Accordingly, we mandate a review-before-merge workflow for MediaWiki core and also for any extension we deploy.

= The merge request model =

The abstraction for code review in GitLab is the merge request. The terminology differs, but this is essentially the pull request model first popularized by GitHub: A developer makes a branch, makes one or more commits, and submits a request to merge those changes. Depending on the developer's access level, branches may be pushed either to a copy of the repository forked to their personal account, or directly to the mainline repository.

Once a merge request is submitted, reviewers may comment or make suggestions. In response to feedback, the developer can push more commits to their work branch. Reviewers may then either merge or close the request, as appropriate

Users with the authority to merge a merge request may also push commits to the underlying branch.

Upstream documentation:


 * Merge requests
 * Getting started with Merge Requests

= Review workflow =

Upstream documentation:


 * Reviewing and managing merge requests

Finding merge requests to review

 * Where your attention has been requested: (TODO)
 * Within a project: (TODO)
 * Within a group of projects: (TODO)

Inline suggestions
GitLab comments support inline suggestions for simple changes. This is a powerful feature, particularly for small, uncontroversial changes such as typo fixes or style tweaks.

As a reviewer, you can add a suggestion using the following syntax (also available by clicking the "Insert suggestion" button on the comment formatting toolbar):

```suggestion:-0+0 replacement text here ```

Best practices:


 * Use inline suggestions for minor changes (typos, style issues, clarifying comments).
 * Multiple suggestions should generally be applied as a batch.
 * A merge request with accepted suggestions should typically be squashed on merge in order to avoid noisy commits.

Requirements to merge

 * All discussions on the merge request must be resolved.