[wdfx]

The problem with this though, is that commonly a requirement (ticket) does not map exactly to a single code repository.

I feel that it is breaking encapsulation in a sense to be dealing with issues at the repo level. The repo and the code are implementation details of the business requirements. The tickets describing requirements belong at the next level up of abstraction?

[mushakov]

Hi there! I lead the product teams for planning features at GitLab. Issues at the group level are in the works to meet this exact need. You can follow the work in this issue https://gitlab.com/groups/gitlab-org/-/epics/8308 . As always, would love to hear from you in the issue if you have feedback about the approach or have follow up questions.

[wdfx]

Thanks for providing this info.

I do use gitlab-ce at home for my personal projects and think it's awesome.

I would recommend it to work in terms of its features for code management and build pipelines.

But I just cannot see any of our product management team wanting to use this for Roadmap/Epic/Task tracking at all. Its far too technical and too close to the code, both of which are things they have neither the time, interest or skill to interact with. Management are comfortable with Jira (and some of the extended Atlassian suite), as it hides the technical stuff away and allows them to focus on the management data.

I don't know what the perfect solution looks like though, and I also haven't spend the time to exhaustively try all the competing products either.

[arueda]

Hey `wdfx` GitLab team member here. :)

>[Roadmap/Epic/Task tracking] Its far too technical and too close to the code

I'm a Product Manager in the Plan stage at GitLab and I'd love to learn more about this impression. Would you be willing to share more either in thread or on a call?

Specially, I'm trying to understand what about the GitLab Plan tools (epics, roadmaps, etc) feel dev-centric?

[peanball]

There are issues at group / org level in GitLab that can span such tasks.

[imp0cat]

Also, you can create a special project to keep general issues (and use CI in this project to run Gitlab Triage bot to help you with issue management).

[john_cogs]

GitLab team member here.

One way to approach this would be using Epics [0], which can live at the group-level. Child epics and/or issues can then be used for more finely tuned requirements.

0 - https://docs.gitlab.com/ee/user/group/epics/index.html

[afandian]

I should point out that multi-level epics are only available at Gitlab's $99 per user per month level. We wanted to use them, but it's not worth that much. Jira is a lot more flexible and cost effective in this regard.

[kwanbix]

99 per user per month is crazy expensive IMHO.

[afandian]

And it's not just for developers who might be using the expensive stuff (git, storage, CI minutes). Also for members of the org who only use tickets.