Gitlab segmentation: subgroups

[Agustín Benito Bethencourt <agustin benito codethink co uk>]

Hi all,

## Background

As the number of repos grow and as the nature of tasks expand the technical 
nature, the default way to approach scalability  in Gitlab is to structure 
projects in sub-groups. This approach has several advantages, according to the 
Gitlab documentation:

* "With subgroups (aka nested groups or hierarchical groups) you can have up 
to 20 levels of nested groups, which among other things can help you to:
        * Separate internal / external organizations. Since every group can have 
its own visibility level, you are able to host groups for different purposes 
under the same umbrella.
        * Organize large projects. For large projects, subgroups makes it 
potentially easier to separate permissions on parts of the source code.
        * Make it easier to manage people and control visibility. Give people 
different permissions depending on their group membership."

* More info about subgroups
        * Gitlab documentation: https://docs.gitlab.com/ee/user/group/subgroups/
                * There are several limitations when using subgroups but they are 
close to irrelevant to us at this point, I think.
        * Commercial documentation: https://about.gitlab.com/features/subgroups/

My experience supports these arguments.

## Proposal:

I would like to propose:

* To create a subgroup for non-technical tasks where myself and others can 
work on tasks that are not directly related with code.

* When the above consolidates, and if the approach becomes successful, discuss 
the convenience of expanding this approach to the existing repos.
        * For the segmentation of code repos/projects, I suggest to think more in 
terms of development vs delivery vs maintenance than of functionality or 
usage/purpose, as the driver for such potential structuring. 

## Impact

Advantages for us:

* To segment technical/code repos from no-technical tasks would allow us to 
have a different permission schema to each subgroup. For instance, a person 
with my profile would not have Owner permissions on code repos but she/he might 
have them on other sub-projects, spreading the Gitlab management effort.

* We can keep overall milestones but labels, tickets, boards structure, etc 
could be restricted per subgroup, increasing flexibility and reducing out of 
context choices in many fields (labels, users, etc.) we use everyday . 

* Cleanness/clarity: as the number of projects grow, structure them help 
newcomers to contribute. I think we have reach a point in which adding some 
structure will help to identify where is what and what for. 
        * We can have a general bug tracker instead of "per subgroup/project" bug 
tracker, for instance.

* It will be helpful in the future with notifications and other integration 
with third party apps, including becoming part of a different Gitlab service, 
to keep some level of segmentation like the one provided by subgroups.

Risks:

* Downstream might depend on current URLs.
        * Mitigation: notifications in advance.

* Effort required in creating groups and checking permissions.
        * Mitigation: the re-structuring can be done repo by repo, providing time 
for those involved to check permissions, instead of "at once".

* Wiki/announcement links stop working
        * Mitigation: general redirection at DNS/web server level or previous 
identification and correction afterwards.

Best Regards
-- 
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd