GitLab/Policy

Users
A user is a unique identifier for a person identified by an email. In the gitlab-test instance, users are local to that instance. Each user has a unique username. A user's username is a unique top-level namespace in GitLab.

In future, users will login to GitLab with their LDAP developer accounts. A user's name would be their LDAP  (as is the case with Gerrit). This avoids using ReCaptcha software for account creation.

Users with Developer privileges—those who merge code—must have two-factor authentication enabled on their account.

Namespace Groups
Groups are local to the GitLab instance. Groups can act as containers for subgroups.

Top-level groups act as namespaces. Namespaces should be reserved for large functional areas that encompass projects. This is not the same thing as a team. The team responsible for a code project may change.

For example,  is a namespace group that can contain the project. More layers of group nesting may be useful. For example, a  namespace group is a subgroup of the   namespace group and may contain MediaWiki extensions.

mediawiki/ ├── [core] ├── extensions │   ├── [extension1] │   ├── [extension2] │   └── [extension3] ├── libs │   ├── [library1] │   ├── [library2] │   └── [library3] ├── skins │   ├── [skin1] │   ├── [skin2] │   └── [skin3] ├── tools │   ├── [tool1] │   ├── [tool2] │   └── [tool3] └── [vendor]

User Groups
Groups in GitLab can contain members. Members of a group are individual users or other groups. User groups can be useful models of the real world.

Examples of useful abstractions that should be user groups are employers (for example "Wikimedia Deutschland") and teams (for example "Release Engineering").

User groups should be kept under the top-level namespace group "people". Initially, there will be a small number of user groups. If the purpose of a group is to model a real-world group then a subgroup under the people namespace is appropriate.

people ├── trusted-contributors ├── wmde │   ├── [team1] │   ├── [team2] │   └── [team3] └── wmf ├── [team1] ├── [team2] └── [team3]

Security groups
There may be additional ad-hoc groups that contain both users and projects for security purposes.

Projects
Projects are collaborative digital spaces to write, review, test, merge, and browse code in GitLab. Projects belong to either an individual user, a namespace group. Projects do not belong to user groups.

Permissions
Projects have features that contain specific permissions.

To ensure everyone can contribute, projects should allow "Everyone with Access" to create merge requests. This is a setting for each repository under "Settings" > "General" > "Visibility, project features, permissions" > "Repository". This will allow all users to create merge requests for a project.

The "Pipelines" setting in public namespaced projects should be set to "Only Project Members". This ensures that only project members with Reporter privileges are able to run tests on a particular project.

Members
Projects have members with privileges. Project members are users or user groups. User groups are the easiest way to add a team or employer to a project as a member. If there exists no real-world group that can be modeled as a user group then it is appropriate to add individual users as privileged project members. It would be inappropriate to create a user group solely for the purposes of project maintainership. For example, a group named "projectx-maintainers" is discouraged — maintainers of "projectx" should be added to projectx as individual users.

Namespace inheritance
Projects belong to namespace groups. Namespace groups may contain members. Members of a namespace are also members of a project in that namespace. For example, if you are a member of the  namespace group you will be a member of the   project.

Privileges
Groups in GitLab contain members. These members have one of 5 roles:
 * Guest
 * Reporters
 * Developers
 * Maintainers
 * Owners

You can read more about permissions in the upstream GitLab permission documentation. GitLab allows you to build a permission model by policy. Our policy is outlined on this page.

Any user should be able to create or comment on a merge request. Reporters can run tests for a given project. Developers can create branches on the project to use for merge-requests in the  namespace. Developers can also approve and merge code for a project. Maintainers can reconfigure a project, change privileges, and update merge and squash options. Owners can delete and rename projects.

Developers and Maintainers can approve and merge their own merge requests similar to a self-+2 in Gerrit. 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.