Thinking out loud: how easy is it to move/rename and/or merge these groups if when the corresponding teams change (disband, reorganize, etc, etc).

Thinking out loud: how easy is it to move/rename and/or merge these groups if when the corresponding teams change (disband, reorganize, etc, etc).

We've explicitly decoupled the people groups from the project groups for largely that reason, and are hoping to have project groups eventually defined more by functional area than by a close mirror of org structure, though some of that is probably inevitable. I fully expect that team groups will need re-creating at various points.

I'll note that GitLab does support project renames, I think, along with automatic redirects, but for groups I think they recommend re-creating the group.

Hey @brennen,

This is great! Many thanks.

Could you help me understand how repos and people namespaces differ from each other operationally?

• Created: https://gitlab.wikimedia.org/repos/generated-data-platform
• Created: https://gitlab.wikimedia.org/people/wmf-team-platform-engineering

As a learning experiment I wanted to transfer this repo to https://gitlab.wikimedia.org/repos/generated-data-platform.
I tried following the doc at https://gitlab.wikimedia.org/help/user/project/settings/index#transferring-an-existing-project-into-another-namespace. However, in the settings panel
I'm only given the option to transfer to https://gitlab.wikimedia.org/people/wmf-team-platform-engineering (instead of my desired target).

Is this the expected ownership model / behaviour? If that's the case, is there an import/transfer best practice you'd recommend I follow?

Notes / questions: This scheme overshoots the above-listed set of contributors. We could alternatively define a people/wmf-stream-generated-data-platform or similar if that seems more appropriate. We haven't yet really established a pattern for modeling cross-team collaboration of this sort.

I think that's ok for now. IMHO the contributors set boundaries are anyway loosely defined right now. Cross-team behaviour is something I'd expect we'll see happening more (if we stick to "value stream" team structure). Holler if I can help guinea pig ideas / approaches sometimes down the line.

Could you help me understand how repos and people namespaces differ from each other operationally?

Groups in /people are intended to model groups of humans.

Those can then be invited to groups of projects in /repos.

We have a draft policy document about this here: https://www.mediawiki.org/wiki/GitLab/Policy

That doc needs some refinement, but the basic idea is just to keep organizational structure somewhat decoupled from the layout of projects, so we can update groups in /people as teams & volunteer interests change without micromanaging membership lists on a per-project basis.

I'm only given the option to transfer to https://gitlab.wikimedia.org/people/wmf-team-platform-engineering (instead of my desired target).

Hrm. And, as came up on T293741, forking also won't work. There's something about the permissions model here I need to figure out. If there's not a way to tweak this, we may need to rethink the people scheme. Creating a new project is meant to be self service.