GitLab Next

This issue is being tracked here https://gitlab.com/gitlab-org/gitlab-ee/issues/5135

Our team's use of GitLab requires that a single issue can be associated with multiple milestones. We think that while GitLab as originally conceived may not have needed this, the addition of global (cross-project) milestones means this is now necessary for those global milestones to be useful.

In our use of GitLab, we have both per-project milestones (versions) and global milestones (external commitments / deliverables) that are all real, actual milestones.

Here's our use-case in detail:

We use semantic versioning for our releases. For each release we create a milestone. When we know that an issue will be or needs to be fixed in an upcoming release we mark the issue as being part of that milestone. So we have per-project milestones like spa-5.4, spi-3.3.2, sm-3.1.1, etc.

In this way we can use the milestone features, e.g. being able to see what percent of issues related to the milestone are in progress, closed, etc.

By associating the issues with the released version, we are able to use the milestone as a starting point for e.g. writing release notes.

However we also use milestones to represent external deliverables that cut across projects. E.g. in a staged implementation with a customer, we'll have multiple sets of features we've committed to that have to be delivered across our product portfolio before the customer will move to the next stage of implementation and pay us more money.

GitLab does have existing support for milestones across projects (see #3488 (closed) and #1802 (closed)). So we create a cross-project milestone such as acme-project-phase-1 and set a due date on that milestone (because there really is an externally-committed one). Then we create the feature request and other issues across all of our many projects needed to fulfill the Acme Phase 1 requirements.

This lets us use the features of milestones, such as the deadline, the ability to see issues across many projects, their state, related merge requests, participants, labels, etc. And we can see how close we are to achieving the milestone based on the percentage of closed issues to open issues.

Unfortunately, however, these two uses of milestones conflict with one another. We don't know in advance which per-project milestone is going to correspond to the external-facing milestone, so there's no sensible 1-to-1 mapping. And the deliverables for a particular customer-facing milestone can land across multiple versions even of the same project. They are separately-tracked but overlapping things.

So as we go to make a release of e.g. spa-5.4.1, we end up having to remove the issue from the acme-project-phase-1 milestone so we can add it to the project-level spa-5.4.1 milestone.

That's not a great solution as we lose lots of the benefits of tracking the progress on the global acme-project-phase-1 milestone.

Basically, it seems that really making global milestones work necessitates allowing for an issue to be tracked by multiple milestones.

We can of course hack around it with labels and create a acme-project-phase-1 label, but that thing really is a milestone; it has a due date and when it's done we want to close it out rather than having a label that hangs around in all the label selection UIs forever. And then we lose the benefits of the milestone UI for tracking it.

Basically, both spa-5.4.1 and acme-project-phase-1 are real, actual milestones in our workflow. We'd really like for GitLab to support tracking them both.