Native group milestones

Resources

BE @felipe_artur | FE @selfup | UX @cperessini | PM @victorwu

Problem

• Currently we have no "native" notion of group milestones. Instead, when we create a group milestone, we are really creating multiple project milestones.
• This causes a lot of difficulty with groups. Especially as we expand on groups/subgroups functionality and group boards, we will want a coherent notion of group milestones to aggregate issues together in some time period.

Design

We'll be adding the new concept of milestones scoped to a group, i.e. group milestones.

Group milestones will have the following attributes only:

• Title, Description, Start date, Due date

Possible states of a group milestone:

• Open, Closed
• (Note that you cannot delete a group milestone.)

Important note: A group milestone cannot share a title with a milestone in one of its projects. If the user tries give a group milestone a title that's already being used in one of its projects, an error banner should show up: Milestone title is already in use at the project level

Milestones list view at the dashboard level

• This page currently shows all project milestones across all groups in the instance (that you have access to). There will be no functional changes here. For example, https://gitlab.com/dashboard/milestones.
• Note that group milestones are not shown on this page.
• The view is similar to the group milestones page (below).

Milestones list view at the project level

• For example, https://gitlab.com/gitlab-org/gitlab-ce/milestones.
• No change on this page.

Milestones list view in a group

• This page now combines group milestones (new) and project milestones (existing) from all projects in the group.
• For example, https://gitlab.com/groups/gitlab-org/milestones.
• The one line of text at the top saying Only milestones from GitLab.org group are listed here. should be removed.
• We show all milestones in the same list. This is the simplest approach for a first iteration and we can look into separating them into tabs in the future.
• Next to the name of each milestone we show if it's a group or project milestone. This is new.
• Project milestones
  • The information displayed below (milestone name, start and end dates, number/links to issues/merge requests, links to milestones of respective project milestone pages) is not changed.
• Group milestones
  • The information displayed below should only be start date and due date.
• Progress bar
  • Show the progress bar for project milestones (existing) and group milestones (new).
• Show the edit button if you have the right permissions. (For both project and group milestones.)
• Show the close button if you have the right permissions. (For both project and group milestones.)
• Remove the Delete button in this view (for both project and group milestones), as we want to move away from objects being delete-able.
• Show the New milestone button at the top right corner if you have the right permissions. This button takes you to the page for creating a new group milestone.
• The New milestone button currently takes you to a form where you can create multiple project milestones at once. This view should not be accessible any more.
• No particular requirement of ordering the items in this list view for this iteration. (Whatever is existing/most straightforward works.)

Creating a group milestone

This page will be a simple form where you can enter the milestone's basic attributes. This form is identical to the project milestone form.

Editing a group milestone

Just like creating a milestone, the project milestone form can be reused here

Project milestone view

• Example: https://gitlab.com/groups/gitlab-org/milestones/91?title=9.1.
• No change in this view.

Group milestone view

• The group milestone page will show its basic attributes as shown in the mockup. Other features (how many issues belong to it, burndown chart, etc.) are out of scope.

For group milestones we won't be able to show the list of issues and merge requests inside the milestone page in the first iteration. For that reason, we show links to the full lists in the content section.

For example, the issues link in the group milestone 9.2 in the group GitLab.org would take you to:

https://gitlab.com/groups/gitlab-org/issues?scope=all&state=opened&milestone_title=9.2

Associating an issue or merge request with a milestone

• A given issue/MR can only be associated with one milestone. An issue/MR can be associated either with a project milestone or a group milestone.
• An issue/MR can only be associated with a group milestone if the group is the direct parent of the issue/MR's project (other layers of subgroups are out of scope)
• When assigning a milestone an issue/MR, we show group and project milestones in the same dropdown, there is no difference between them.
• Slash commands and other ways to associate/disassociate an issue/MR with a group milestone are out of scope.
• System notes are out of scope.

Filtering issues and merge requests by group milestones

It'll be possible to filter issues and Merge Requests by group milestone in addition to by project milestone. This will be possible in the project pages:

• https://gitlab.com/group/project/issues
• https://gitlab.com/group/project/merge_requests

Filtering in other areas of GitLab such as the group page and the board are out of scope.

No changes to any UI. Project milestones and group milestones are indistinguishable in the UI here (similar to group labels and project labels).

Moving issues from one project to another project

• Consider that your issue is in Project P. Your issue is associated with the P project milestone called BetaRelease. Now you are moving the issue to Project Q. P and Q may or may not be in the same group.

  • Look for a project milestone in Q called BetaRelease. If it exists, then the new issue in Q should have that project milestone.
  • If Q does not have any project milestone called BetaRelease, then the new issue should not have any milestone associated with it.

• Consider that your issue is in Project P. P belongs to Group G. G has a group milestone called AlphaRelease. Your issue is associated with that AlphaRelease group milestone. There is another Project Q which belongs to Group G. There is another Project R which belongs to another Group H.

  • Suppose you are moving your issue from P to Q. The new issue retains the same group milestone.
  • Suppose you are moving your issue from P to R.
    • Look for a group milestone in H called AlphaRelease. If it exists, then the new issue in R should have that group milestone.
    • If H does not have group milestone called AlphaRelease, then the new issue should not have any milestone associated with it.