### Intended users * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) ### Problem to solve The relationship between releases and tags is not entirely clear in the UI. While convenient, generating releases from tags can cause a cascading effect of problems if the user does not realize the tag they just created _already has a release associated to it_ ([see insights](https://gitlab.com/gitlab-org/gitlab-design/-/issues/1670#note_668933228)). > **From [UX Scorecard](https://gitlab.com/gitlab-org/gitlab-design/-/issues/1670):** > “So I think, create a tag = create a release, not sure. It is not what the doc say... doc says associate tag with a release, but can a tag exist without a release?” > > “The UI behavior still confused me, it didn't map 100% what the doc say, the tag can be associated with a release \[...\] Clearly communicate the relationship between release and tag.” > **From `@patrikhuber` in https://gitlab.com/gitlab-org/gitlab-ce/issues/56969**: > “Only the "tags" that I gave a description in the "Tags" page on GitLab turn up on the Releases page. The other ones turn up of course on the Tags page, but not on the Releases page. I believe this to be quite confusing. Furthermore, what if I add "Release notes" now on the Tags page? Will it suddenly turn up on the Releases page? And then this is information duplication in the first place - there will be the same text/release notes displayed both on the Tags and Releases page.” ### Proposal Make relationship between Tags and Releases clearer in the UI by adding a block of copy (and possibly illustration) to: - Make sure users understand how creating a Tag can generate a Release - Have a better chance of adopting Releases in their workflow <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> <!--- Use the following resources to find the appropriate labels: - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section. Other sections to consider adding: ### Release notes What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " ### User experience goal What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/