Skip to content

Support release association to group milestones in UI

Problem

Project milestones and tags support being connected to Releases. Today users can only associate milestone to releases at the project level.

We believe we need to support both grouping of tags in a group and the ability to associate group milestones. There are two angles:

  1. For users NOT leveraging milestones for planning, the ability to link related code/tags is super valuable.
  2. A project/team's milestones can be different than the group - so let's take the release-cli for example, we would have a project milestone of v1.0 that will be ready in the GitLab.org group milestone of 13.4.

User experience goal

The user should be able to add group milestones to a release in the Edit release form, and see the group milestone data in the Release pages.

UX DoD

Click this to collapse/fold the UX DoD 🔽

Entry Criteria for Design

  • Problem has been validated
  • Has UX effort accounted for in long term cycle, we know unknowns

Criteria for UX DoD

  • UX label is added to the issue
  • User stories and acceptance criteria have been created
    • Edge cases were considered
  • Cross-team dependencies have been identified, if applicable
  • Prototype or mock for each user story have been created
    • Empty states
    • Responsiveness
  • ~~If changes involve copy, UI text label has been added~~
  • Pajamas: UI Component design have been identified
    • Pajamas issue is created (new workflow)
  • Marked as Ready for engineering evaluation per user story moved into workflowplanning breakdown & needs weight

Entry Criteria for Ready for Development

  • Scope has been defined and reviewed with engineering
  • User stories have been weighed and are less than 5 MRs
  • Create new issues for follow up user stories

Criteria for Engineering DOD (in addition to defined process)

  • UX review for MRs that include user experience changes - mandatory for frontend that has impact to UI/UX
  • Update SSOT in issues:
    • Update prototypes of deliverables
    • Add link to documentation
  • Create new issues for follow up and open scope

Intended users

Proposal

JTBD 📍

When managing several projects that belong to the same group, I want to associate the same group milestone to multiple project-level releases, so that I can have a global view of what is being released in my group.

User flow

Rachel would like to orchestrate a single release for related projects that are assembled together in a group. They heard that GitLab supports cross-project release orchestration through milestones, which will help them to manage all of their group's releases in one central place.

  1. Rachel opens the GitLab app and navigates to their project.
  2. They navigate to Releases > Edit release.
  3. In the Edit release form, they see a dropdown with the option to associate milestones to the Release.
  4. They can select an existing milestone from the dropdown, or search for all milestones (group & project level).
  5. They can select 1 or N group or project milestones.
  6. Selecting 1 or multiple group milestone(s) closes the dropdown.
  7. Saving the form takes them to the Release detail view.
  8. The group milestone is associated to the Release.
  9. They can see the counter for closed issues in that given milestone.
  10. Rachel clicks the milestone name in the Release detail view and is taken to the Milestone detail view, where they can see all data for issues, merge requests, labels, etc. in that group milestone.

User stories

Theme: Allow user to associate a group milestone in the Edit release form

🔮 See UX prototypes in the Design tab

Acceptance criteria
  • In the Edit release form, user should be able to see and search for group milestones in the Milestone dropdown menu.
    • We want to reuse the dropdown behaviour being introduced in !35265 (merged) -- show separators and badge counters for project and group milestones in the list.
    • A helper text should be added below the existing form component.
  • Clicking a group milestone adds it to the selection in the dropdown.
    • User should be able to add 1 or multiple project or group milestones at the same time.
  • All existing interaction in the dropdown selector stays the same.
    • In the create milestone and manage milestones menu options, user should still be redirected to the project milestone pages.
  • When saving the changes in the Release form, user is taken to the Release detail view. The group milestone is now added to the release.

Theme: Allow user to see a group milestone selection in the Releases page

🔮 See UX prototypes in the Design tab

  • When associating 1 or multiple project milestones to a release, user should see the information reflected in the Release item (overview and detail page).
  • User should see:
    • The group milestone name (clickable) in the UI.
      • Clicking the group milestone name in the Release overview/detail page should take the user to the group milestone detail view.
    • The data for closed issues from the milestone accounted in the progress bar.
    • The issues counter for all the milestones associated to the release.
  • When a combination of group and project milestones are associated to a release, the counters should calculate them accordingly.
    • Issues that are added to a group milestone and a project milestone at the same time should be calculated only once in the counter/progress bar.

Issue breakdown

frontend

backend

Follow up
  • We need to make sure the issues counter should link to the group issues list if a group milestone is associated to the release item.

Future iterations

A few ideas of what could be included or looked at in future iterations:

  • Allow user to see releases associated to a group milestone in the Milestone overview page #221223 (closed)
  • Allow user to see releases associated to a group milestone in the Milestone detail page #221224
  • Associate a milestone to a release when creating a New Release item (create release form) #214244 (closed)
  • Associate a Releases to a group milestone from the Milestones UI #221226

Permissions and Security

  • members with no access (0) should not be able to update or edit group milestones
  • Guest (10) members should not be able to update or edit group milestones
  • Reporter (20) members should not be able to update or edit group milestones
  • Developer (30) members who DO NOT have access to the group should not be able to update or edit group milestones.
  • Developer (30) members who DO have access to the group should be able to update or edit group milestones.
  • Group & Project Maintainer (40) members should be able to update or edit group milestones.
  • Owner (50) members should be able to update or edit group milestones.

Documentation

Yes, this feature requires updates to the Releases and Milestones documentation pages.

What is the type of buyer?

GitLab Premium

Is this a cross-stage feature?

Yes, milestones is a capability that falls under devopsplan ~"Category:Project Management".

Links / references

Edited by Sean Carroll