Instance Level Epics
Problem to solve
On a call with a large customer yesterday, they mentioned it would be helpful to have epics at the instance level in order to link issues in various groups. Imagine a customer who has GitLab groups broken out by department, for example dev, product, qa, etc. but is doing portfolio management and linking tasks to a single epic amongst these groups.
Proposal
Create a new construct at the top level (name TBD) that can take a group as a child. This top level construct can inherit epics and issues but not members.
Group A
Group B
Group C
Group D
Group E
Group A and E are top-level groups; they have nothing in common, and no parent group. Groups B, C, and D can all use labels, milestone, epics, etc. from Group A. All members of group A have at least that access in groups B, C, and D.
My proposal would be to allow you to create a new top-level group that acts as a 'parent' for groups A and E. This would have to be limited in scope as it could be confusing. For instance, let's say:
- You can create a new 'meta-group', Group F.
- This has to be a top-level group.
- You can add top-level groups to this group as 'children'.
- EDIT: a top-level group can only be a member of a single 'meta' group. It can only be added by an owner of both groups.
- This cannot have any subgroups or projects (can change this later).
- This can have milestones, labels, boards, and epics.
- Milestones and labels can be used by the 'child' groups. Boards and epics can see issues and epics in the 'child' groups.
- Other group-level features are for that stage group to decide.
- Membership to this group does not inherit to the groups below.
This proposal accomplishes a couple of things:
- There's an easy place to discover things.
- It allows a limited decoupling of group-as-collection-of-users and group-as-container-for-epics-and-such.
- In particular, you don't have to worry about giving people access to everything in the other top-level groups through adding them here.
- It works well with existing group structures. You don't have to move everything into the same top-level group to get it to work.
Permissions and Security
We will need to answer who would have permissions to manage an instance level epic.
Problems Identified
This may introduce another difference between self-managed and GitLab.com.