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?
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.
>[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?
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.