Nesting groups without Nesting Group Path
Or Sub-groups as Graphs
Problem to solve
I need to create Epics/Milestones that cover a wide range of projects that are not child of a master group.
Intended users
Managers needing to extract statistics and numbers across projects in a complex organizational structure.
Further details
Having groups and sub-groups as a tree is limiting in a few ways. It attempts to encompass permissions, organization, data visibility under that same constrained concept.
Proposal
Having nested groups act more as graphs rather than trees. Meaning 1 group can have many children, but also 1 group can have many parents. Here are a few implications:
-
Graph-like children would not inherently require a long path (/dad/son/grandson) but you would be able to use one nevertheless for organizational purposes only.
-
Groups would become more than just namespace. They would be tools to gather important data. Check this use-case:
- A company self-hosts a GitLab instance for their projects
- Project A is an important company-wide project.
- Now Department X got in charge of the major development of Project A along with their other smaller projects.
- Departments Y and Z still work in Project A.
- We can't move
/project-a
to/dep-x/project-a
. It's not exclusively ours. - Yet we need to see it's info in our group board, roadmap, relate the project's issues with our milestones.
I hope I'm clear enough.
Permissions and Security
Probably huge security implications if not thougth through.
Documentation
Availability & Testing
What does success look like, and how can we measure that?
We will be able to reference projects in group boards, epics and group milestones without changing their path or any strong organizational semantics.
What is the type of buyer?
It sounds like Ultimate, though due to the nature of the change I believe it would be required to replace the current behavior entirely rather than switching on demand.