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 =

Upstream documentation:
 * Merge requests

The central abstraction for code review in GitLab is the merge request. The terminology differs slightly, but this is essentially the pull request model originally popularized by GitHub: A developer makes a branch, either on a copy of the repository forked to their personal account or directly on the mainline repository, and authors one or more commits before submitting a request to merge those changes.

= 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.