Change Details

We've [[https://www.mediawiki.org/wiki/GitLab/Policy#MediaWiki_permission_model|roughed out a model under mw.org/GitLab/Policy]]: > For reference, this uses the GitLab roles described at: https://docs.gitlab.com/ee/user/permissions.html > > For `repos/mediawiki`: > * It seems like people can mostly be Developers. > * A smaller group of Maintainers can //create// repos and sub-groups than the overall set of Developers. > * `main` will be a protected branch > * Developers can: > ** Merge to `main` via Merge Request > ** Create new work branches (we will establish a convention for names, e.g. `review/[username]/[topic]`, and likely enforce restrictions on this in code) > * Maintainers can > ** Create new sub-groups and projects > ** Push directly to protected branches (`main`, release branches?) > * Contributors who are not a member of projects can fork projects and submit merge requests for consideration Questions: * What are we missing / forgetting? * This should probably be explicit about group membership imported from LDAP groups. * What other existing Gerrit configuration do we need to be sure to account for? * Does this sound like it will work?

# Summary This task is for figuring out a policy for //who// can do //what// with projects under `/repos/mediawiki` on GitLab. `/repos/mediawiki` is the designated namespace group for MediaWiki core, extensions, skins, services, etc. It will be laid out approximately as described at [[https://www.mediawiki.org/wiki/GitLab/Policy#MediaWiki_namespace|mw.org/GitLab/Policy#MediaWiki_namespace]]: ``` repos/mediawiki/ ├── [core] ├── extensions/ │   ├── [extension] │   └── ... ├── [extensions-all] ├── libs │   ├── [library] │   └── ... ├── services/ │   ├── [service] │   └── ... ├── skins/ │   ├── [skin] │   └── ... ├── [skins-all] ├── tools/ │   ├── [tool] │   └── ... └── [vendor] ``` This is intended to be broadly similar to the current layout in Gerrit, although some details will have to change. For example, while groups can contain both sub-groups and projects, a project cannot act as a container for other projects. **Please do not bikeshed this part too hard**. We have a proof of concept for a bot that will assign GitLab group membership based on LDAP groups, and we also have the capability to import Gerrit groups for specific projects as they are migrated. # Draft policy We've [[https://www.mediawiki.org/wiki/GitLab/Policy#MediaWiki_permission_model|roughed out a model under mw.org/GitLab/Policy]]: > For reference, this uses the GitLab roles described at: https://docs.gitlab.com/ee/user/permissions.html > > For `repos/mediawiki`: > * It seems like people can mostly be Developers. > * A smaller group of Maintainers can //create// repos and sub-groups than the overall set of Developers. > * `main` will be a protected branch > * Developers can: > ** Merge to `main` via Merge Request > ** Create new work branches (we will establish a convention for names, e.g. `review/[username]/[topic]`, and likely enforce restrictions on this in code) > * Maintainers can > ** Create new sub-groups and projects > ** Push directly to protected branches (`main`, release branches?) > * Contributors who are not a member of projects can fork projects and submit merge requests for consideration # Questions * What are we missing / forgetting? * This should probably be explicit about group membership imported from LDAP groups. * What other existing Gerrit configuration do we need to be sure to account for? * Does this sound like it will work?

# Summary This task is for figuring out a policy for //who// can do //what// with projects under `/repos/mediawiki` on GitLab. `/repos/mediawiki` is the designated namespace group for MediaWiki core, extensions, skins, services, etc. It will be laid out approximately as described at [[https://www.mediawiki.org/wiki/GitLab/Policy#MediaWiki_namespace|mw.org/GitLab/Policy#MediaWiki_namespace]]: ``` repos/mediawiki/ ├── [core] ├── extensions/ │   ├── [extension] │   └── ... ├── [extensions-all] ├── libs │   ├── [library] │   └── ... ├── services/ │   ├── [service] │   └── ... ├── skins/ │   ├── [skin] │   └── ... ├── [skins-all] ├── tools/ │   ├── [tool] │   └── ... └── [vendor] ``` This is intended to be broadly similar to the current layout in Gerrit, although some details will have to change. For example, while groups can contain both sub-groups and projects, a project cannot act as a container for other projects. **Please do not bikeshed this part too hard**. We have a proof of concept for a bot that will assign GitLab group membership based on LDAP groups, and we also have the capability to import Gerrit groups for specific projects as they are migrated. # Draft policy We've [[https://www.mediawiki.org/wiki/GitLab/Policy#MediaWiki_permission_model|roughed out a model under mw.org/GitLab/Policy]]: > For reference, this uses the GitLab roles described at: https://docs.gitlab.com/ee/user/permissions.html > > For `repos/mediawiki`: > * It seems like people can mostly be Developers. > * A smaller group of Maintainers can //create// repos and sub-groups than the overall set of Developers. > * `main` will be a protected branch > * Developers can: > ** Merge to `main` via Merge Request > ** Create new work branches (we will establish a convention for names, e.g. `review/[username]/[topic]`, and likely enforce restrictions on this in code) > * Maintainers can > ** Create new sub-groups and projects > ** Push directly to protected branches (`main`, release branches?) > * Contributors who are not a member of projects can fork projects and submit merge requests for consideration # Questions: * What are we missing / forgetting? * This should probably be explicit about group membership imported from LDAP groups. * What other existing Gerrit configuration do we need to be sure to account for? * Does this sound like it will work?