3 ms·

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 encapsulatio

by wdfx 3y ago

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?

peanball 3y ago
There are issues at group / org level in GitLab that can span such tasks.
- imp0cat 3y ago
  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).
deleted 3y ago
[deleted]
john_cogs 3y ago
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 https://docs.gitlab.com/ee/user/group/epics/index.html
- afandian 3y ago
  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 3y ago
    99 per user per month is crazy expensive IMHO.
    - afandian 3y ago
      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.
mushakov 3y ago
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 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 3y ago
  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 3y ago
    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?

by wdfx 3y ago

peanball 3y ago

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

imp0cat 3y ago
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).

deleted 3y ago

[deleted]

john_cogs 3y ago

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 https://docs.gitlab.com/ee/user/group/epics/index.html

afandian 3y ago
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 3y ago
  99 per user per month is crazy expensive IMHO.
  - afandian 3y ago
    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.

mushakov 3y ago

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 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 3y ago
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 3y ago
  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?