GitLab/Policy

Users
In the gitlab-test instance, users are local to that instance. In future, users in GitLab should be backed by our shared LDAP developer accounts. Login would be done with a user's LDAP  as was done with Gerrit.

Groups
Groups are local to the GitLab instance. Groups are used for multiple purposes in GitLab. A group may contain a project or another subgroup. You can nest subgroups past the point of practical advantage. In practice, a top-level group to define a namespace should contain projects. For example, the  group is a namespace under which we may nest. Additional layers of group nesting may be useful. For example, a  group may contain MediaWiki extensions.

Who can review and merge code in GitLab
Any user should be able to comment on a merge request, however only users with Developer- or Maintainer-level permissions for a given repository can merge code.

Self-merge is discouraged by policy. Merging your own code without approval from a reviewer may be grounds for revocation of privileges.

Merging a change to the MediaWiki core or an extension deployed by Wikimedia is a big deal. Your merge could cause Wikipedia or other sites to fail. It could create a security vulnerability that allows attackers to delete or corrupt data, or to gain access to private information. And in the more common case, it could cause technical debt to increase if the code doesn't have tests, is poorly implemented or poorly socialized. You should carefully read this document and all relevant policies before merging a merge request.

Maintainer permissions are a strong expression of trust, and trust is maintained through good judgement and careful action.

In code review, design discussions, and bug comments, those with merge abilities have a special responsibility to see from others' points of view.