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 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, authors 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.

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.