Multiple milestones per issue or merge request
Problem 1: Users (customers have expressed this problem, and it's in the Agile methodology) have asked for a way to differentiate between scoping work to a sprint/iteration (i.e. a finite period of time) versus identifying a feature that will go toward a particular release/version. Currently GitLab has now way to support this workflow. (Note that at GitLab, we don't need this feature in our current process since our monthly sprints/iterations are 1-1 with minor releases, (i.e. .x releases)).
Problem 2: Users (customers have expressed this problem) want a particular feature to be exposed to multiple releases, so that various stakeholders who care, can know. For example, a single change in a backend service benefits the mobile app and a web app. The mobile app people want to expose that change to the mobile app stakeholders, and same for the web app. This is currently not possible in GitLab since an issue can only be associated with one milestone. So that issue/feature cannot be readily exposed to multiple releases.
- Support assigning multiple milestones per issue or merge request.
- This is a boring solution since it doesn't require us to invent a brand new field/attribute for issues/mrs. Furthermore, if you do invent a brand new field/attribute, you have to worry about naming/re-naming which is a big problem. And also, milestones are already deeply integrate with issues, mrs, boards, and other places in GitLab. If we invent a new attribute/object, we would have a lot more work ahead of us to integrate that into all the other places in GitLab.
- By allowing for multiple milestones per issue/mr, we instantly have all the benefits of GitLab, but now users can support additional workflows and solve their problems.
- Also, we trust users to be careful and know when they are using a milestone to indicate a sprint/iteration versus a release. (For the case of GitLab, it doesn't matter since it is 1-1.) So for example, if you are using a milestone to represent an iteration/sprint, you would assign a start date and end date to the milestone. And you would use the burndown chart to observe the sprint/iteration burndown. But if you use a milestone as a release, you would only use the end date of the milestone to represent the release date. You likely wouldn't use the burndown chart because it wouldn't make sense in that context. This design reduces the complexity of GitLab by allowing us to use milestones for multiple reasons.
Design artifact scope
- Consider if this is a good solution for solving the problem of having separate
- If this is a good solution, consider all the UI that needs to be changed, system notes, quick actions, notifications, how to indicate multiple milestones in issues and merge requests.