## 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. 1. 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 <details> <summary>Click this to collapse/fold the UX DoD 🔽</summary> #### Entry Criteria for Design - [x] Problem has been validated - [ ] Has UX effort accounted for in long term cycle, _we know unknowns_ #### Criteria for UX DoD - [x] ~UX label is added to the issue - [x] User stories and acceptance criteria have been created - [x] Edge cases were considered - [x] Cross-team dependencies have been identified, if applicable - [x] 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)~~ - [x] Marked as Ready for engineering evaluation per user story moved into ~"workflow::planning breakdown" & ~"needs weight" #### Entry Criteria for Ready for Development - [x] Scope has been defined and reviewed with engineering - [x] User stories have been weighed and are less than **5 MRs** - [x] Create new issues for follow up user stories #### Criteria for Engineering DOD ([in addition to defined process](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#definition-of-done)) - [ ] 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 </details> ### Intended users * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) ### 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](https://design.gitlab.com/getting-started/personas#persona-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. 1. They navigate to `Releases` > `Edit release`. 1. In the `Edit release` form, they see a dropdown with the option to associate milestones to the Release. 1. They can select an existing milestone from the dropdown, or search for all milestones (group & project level). 1. They can select 1 or N group or project milestones. 1. Selecting 1 or multiple group milestone(s) closes the dropdown. 1. Saving the form takes them to the `Release detail view`. 1. The group milestone is associated to the Release. 1. They can see the counter for closed issues in that given milestone. 1. 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](https://gitlab.com/gitlab-org/gitlab/-/issues/121476/designs/group-milestone-1.png) ##### 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 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35265 -- 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](https://gitlab.com/gitlab-org/gitlab/-/issues/121476/designs/group-milestone-5.png) - 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 * [Add Group milestones API (GET) methods to api.js](https://gitlab.com/gitlab-org/gitlab/-/issues/232520) * [Update Release pages Vuex stores to handle Group milestones assocaited with a release](https://gitlab.com/gitlab-org/gitlab/-/issues/232530) * [Update the milestone dropdown combobox to display separated sections and badge counters](https://gitlab.com/gitlab-org/gitlab/-/issues/232569) * [Populate the milestone dropdown combobox on the Release edit/new page with Group milestones](https://gitlab.com/gitlab-org/gitlab/-/issues/232577) * [Display group milestones on the Releases page](https://gitlab.com/gitlab-org/gitlab/-/issues/232581) ~backend - [Allow for project releases to be associated with group milestones in the database](https://gitlab.com/gitlab-org/gitlab/-/issues/235387) **closed - duplicate** * [Support Group Milestones to be associated with Project Releases in API](https://gitlab.com/gitlab-org/gitlab/-/issues/235391) **completed** * [Expand Releases GraphQL endpoint for Group Milestone](https://gitlab.com/gitlab-org/gitlab/-/issues/235494) ##### 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 https://gitlab.com/gitlab-org/gitlab/-/issues/221223 - Allow user to see releases associated to a group milestone in the Milestone detail page https://gitlab.com/gitlab-org/gitlab/-/issues/221224 - Associate a milestone to a release when creating a New Release item (create release form) https://gitlab.com/gitlab-org/gitlab/-/issues/214244 - Associate a Releases to a group milestone from the Milestones UI https://gitlab.com/gitlab-org/gitlab/-/issues/221226 ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> * [ ] 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? <!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ~"GitLab Premium" ### Is this a cross-stage feature? <!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features --> Yes, ~milestones is a capability that falls under ~"devops::plan" ~"Category:Project Management". ### Links / references