# Best practices for the usage of the CentOS namespace on gitlab

This document highlights the best practices SIGs interested in using the CentOS namespace on gitlab.com

should follow.

## Login in

The first thing to understand is that gitlab will "link" an existing account

with third party authentication system. In other words, you need to have a

gitlab account and be logged in onto gitlab.com before you can associate your

account with the CentOS Account System (ACO).

So if you do not have a gitlab account, create one. Then visit the following

link [https://id.centos.org/gitlab](https://id.centos.org/gitlab) to associate

your account with CentOS' Account System.

From there on, everytime you visit this link, your group membership defined in

ACO, will be refreshed on gitlab.

## Content

Any and all content hosted on gitlab.com should follow the Requirements the CentOS project has specified

for SIGs: [https://wiki.centos.org/SpecialInterestGroup#Requirements](https://wiki.centos.org/SpecialInterestGroup#Requirements)

## Access

It is expected that access levels are managed via groups on accounts.centos.org (ACO). There are different

ways this can be achieved.

### Simple case

For SIGs who are fine with everyone getting the same level of access, a single group can be created on

https://accounts.centos.org where all the SIG members will be added. This group can then be mapped to that

SIG’s namespace under gitlab.com/centos and be given `owner` access level.

This means, everyone added to this group on accounts.centos.org will be granted `owner` access to each and

every project placed under that SIG’s namespace. This also means, that anyone **not** in this group will have

no access at all.

### More complex case

For SIGs who want or need a more fine tuned model, it is recommended that they create a `groups` namespace under

the SIG’s namespace. In the group namespace will be placed all the groups needed by the SIG and each of this

group will be mapped to a corresponding group on ACO. There should be no project under the `groups` namespace.

The groups can then be given access to any project and the access level of the group can be picked on a

per-project basis.

Here is an example of the structure recommended for the complex case:

```

SIG's namespace

│

├── groups

│   ├── group1-developers [grp1]

│   ├── group2-maintainers [grp2]

│   └── sig [sg]

│

├── rpms

│   └── pkg [grp1+grp2]

│

├── src

│   └──source_tree [grp1]

│

└── sig [sg]

```

## Group membership refresh

To login via ACO on gitlab.com, you must use the following link:

[https://id.centos.org/gitlab](https://id.centos.org/gitlab)

Group memberships are refreshed upon login into gitlab.com. So if someone is added to a group in ACO, they

will need to visit that link again: XXX to have their membership refreshed.

## Group names

For SIGs using the more complex case where multiple groups are required or desired, it is expected that the

extra groups created on ACO to manage access on gitlab.com should follow the corresponding pattern:

`gitlab-<fedora|centos>-<sig>(-<name>)`

Some examples:

- gitlab-centos-hypsercale-maintainers

- gitlab-centos-automotive-kernel-maintainer

- gitlab-centos-automotive-sig-owner

- gitlab-centos-docs-members

- …

## Requesting a namespace or a group

To request a namespace under gitlab.com/centos or the creation of a group on ACO, simply open a ticket at:

[https://pagure.io/centos-infra/](https://pagure.io/centos-infra/)