Decide how we want to use GitLab groups
We had some healthy debate recently between Sean and Josh and between Sean and Chris about how to use GitLab's groups feature. It seems that the three of us all have different ideas about how to use groups.
Josh and I are loosely planning to chat on the phone about this at some point soon which I think would be helpful, but I'd like to use this ticket to jot down some take-away points from research I've done into how GitLab groups work. I'm hoping that if we can all learn more about specifically what groups do, then we'll be better equipped to form a rough consensus around how we want to use them.
What groups do
-
A group contains multiple projects
-
A group with no projects essentially provides no functionality, so it's useful to focus on how groups change the way we use projects.
-
If a user is a member of a group, GitLab automatically grants the user certain permissions to all projects within the group.
- Thus it will behoove us to structure our groups so as to contain projects which require similar permissions for the same users.
- If our groups are too broad, permissions at the group level will need to be relatively restrictive which will prevent us from utilizing the convenience of permission inheritance.
- If our groups are too narrow, the work of creating and maintaining the groups will outweigh the gains of permission inheritance.
-
To make things even more complicated, GitLab also has subgroups.
-
A group provides a list of all projects within it. GitLab also provides a flattened (and searchable) list of all projects
- Thus, finding and discovering projects becomes somewhat easier if we use groups to contain similar projects (somewhat akin to how finding files is easier when we organize them into folders).
- However, projects within sub-groups are not as intuitively discoverable (need to click on "subgroups" yada yada before you can see them)
-
The git URL for a project contains the name of the project's parent group
- Thus, it's worth putting some serious thought into our setup because changing things around later is likely to aggravate people who have already cloned repos.
- If we use subgroups, projects will contains the names of all ancestors, which can yield a pretty long URL if the hierarcy is deep.
-
Issues must be created within a project, but the containing group will display a list of issues across all projects within it.
- We can leverage this feature by keeping the scope of our groups bound to particular topics on which users are likely to work simultaneously.
- If we use subgroups, the "group issue list" only displays the issues within projects of the group (and does not display issues within projects of subgroups).
-
Milestones are attached to specific projects, but it's possible to create a milestone which is attached to multiple projects within the same group (if you create it at the group level). You can't create a milestone which is attached to two projects in different groups. Further, the group gives you a view of all milestones (similar to issues as described above).
-
Labels (for tagging issues and merge requests) can be created at the group level. These group-level labels are automatically available to all projects within the group. (But they're not available to projects within subgroups.)
-
Currently all users have the ability to create new groups, but we could make this more restrictive if we want.