How to deal with multiple teams caring about the same issue
- Users have been asking to be able to associate issues to more than one milestone, or more than one epic. The use case is that this allows you float that issue up to more than one area where different people care about them.
- For the multiple milestone case, you may have different places in GitLab you are tracking features to be shipped. Different teams may care about the same feature being shipped, so it makes sense in that case.
- Similarly for epics, a customer has asked to expose the same feature to multiple epics. So that different teams interfacing with different epics would see that.
- Same for "business releases". If one team ships a product to some business stakeholders, they might want to share that a feature has been shipped. Another team that ships another product some other set of stakeholders might want to share that the same feature has been shipped. (This can be the case if the two products share a common service platform, for example.) If we allow an issue to belong to more than one milestone/epic, this could be solved that way.
- Currently in GitLab, we have not allowed this. But should we allow it? How can we solve this problem in a different way?
- The primary reason in GitLab that we do not support multiple milestones or multiple epics per issue, is that we don't want to double count scope. If an issue is already being worked on in milestone, it shouldn't be also worked on in a different milestone, because then you are double-counting, and that messes up planning, capacity management, etc.
- Could we perhaps consider ways to "mirror" issues or have "shadow" issues that have zero scope, but serve as placeholders?
- Needs more UX consideration and refinement.
- Inviting more people to comment about their problems and use cases.
Edited by Victor Wu