Welcome to the Power Users community on Codidact!
Power Users is a Q&A site for questions about the usage of computer software and hardware. We are still a small site and would like to grow, so please consider joining our community. We are looking forward to your questions and answers; they are the building blocks of a repository of knowledge we are building together.
[How] can issues be nested/dependent past two levels in GitLab?
When utilising Bugzilla, I am able to set issue dependency multiple levels deep, which is essential for project management. Although most CalDAV clients instead expose one-to-many relationships for purely hierarchical task dependency, at least they also permit past two levels.
However, I've yet to ascertain how to achieve this via GitLab. Although I am able to create an issue, and assign tasks as its dependent work items, I'm unable to assign anything as a dependent work item of a task, thereby forcing me to solely indicate one level of dependency.
I hear that “epics” exist, as a possible superordinate of an issue. However, I fear that that solely introduces one additional level of dependency, which isn't nearly sufficient. [1]
The Placement Of The Question
Posted, per tacit endorsement, at posts/288484/history#8.
The Evaluated Version
18.6.0-pre (7bbea341359)
1 answer
Unfortunately, it is not possible. The reasons why have been communicated to me by the relevant project manager: [1]
To performantly compute values from all children in a hierarchy (e.g., weight, count, dates, …). Infinite nesting would be impossible to ensure scalability and speed.
Provide safeguards on usability across all sizes of displays. This will become increasingly important as we introduce additional view types in the near future (e.g., nested table views).
An infinitely recursive set of tasks would be more challenging to estimate within the context of a timebox (e.g., iteration) or a pull-based process like Kanban. It would likely discourage story splitting and right-sizing vertical feature slices during typical planning processes.
Issues are designed for individual or team planning use cases, such as bugs, stories, and so on. Epics are intended to represent a larger body of work spanning multiple projects, which are then decomposed into incremental, iterative deliverables. In GitLab Free, you have Issue > Task. In GitLab Premium, you have Epic > Issue > Task. In GitLab Ultimate, you have Epic > Subepic (up to 7 levels of recursive nesting) > Issue > Task.
Among all the “popular” planning methodologies being utilized by our customers and the wider GitLab community, none of them nest planning artifacts at a depth greater than what we currently support with Epics, Subepics, Issues, and Tasks (at least to my knowledge). So, it’s simply not worth making the system more complex than necessary to support the majority of planning use cases and scenarios.
However, a workaround may exist:
Issues (and Epics) do support a few different relationship types other than parent/child in Premium and Ultimate (Linked items | GitLab Docs). These are much less “structured” in that you can have any work item type linked to another, and there are no limits on how many related items a given work item type (e.g., issue) can have.
I shall confirm when I gain access to Enterprise.
0 comment threads
0 comment threads