Merge project-level labels/milestones into group-level labels/milestones
- We have project-level and group-level equivalents if labels and milestones.
- This is complicated to users and slows down product development because it’s complex.
- It’s not particularly helpful for users either to have the differentiation.
- The complexity is made worse with subgroup support. Subgroup support is a good thing, but projects living at the leaves of a subgroup tree presents many unnecessary edge cases.
- Eliminate having project-level labels and milestones altogether.
- Have some migration strategy to convert project-level labels and milestones into objects at their immediate parent group level.
- For example, simply rename project-level objects by prefixing them with the project name to avoid naming conflicts.
- For teams using groups already, most of the time they don’t need project-level objects. So eliminating them only simplifies their experience and prevents user error.
Project-focused use cases
- GitLab was created with a single project and a single repo. GitLab is powerful because you can start a project and use it right away with little complexity.
- So you should still be able to manage labels from within the project interface. But the UI should be friendly to give the right level of information to the user so as not to be confusing, but still minimal friction.
- Right now, you can have two separate projects with two sets of distinct respective sets of labels/milestones. Some teams might like this level of separation. If we eliminate project-level labels/milestones, the recommended way to solve this problem would be to have the user create an individual group for each project. This would then provide the same level of separation/control as now.
- These have to be addressed.
- Maybe we should make personal namespaces more inline with groups before proceeding.