UX Research for Releases (12.4)
This issue is an umbrella where PM and UX should work together to create a prototype (low- or high-fidelity screenshots or an interactive UI prototype) they believe solves the customer problem for Releases in %12.4
Solution Validation is also relevant for APIs and other technical features that don't require a UI. Communicate these solutions using artifacts such as API docs, workflow diagrams, etc. Involve your Engineering Managers in creating and reviewing these artifacts to gain a shared understanding of the solution and receive input on feasibility.
The next phase (to be planned) should validate that prototype with at least 5 target users through usability testing interviews (in a different issue). UXers should also participate in design reviews to get feedback from peers before proceeding to the next phase.
- Notifications for Releases #26001 (closed)
- Show issue close status on Releases Page https://gitlab.com/gitlab-org/gitlab-ce/issues/66694
- Make it possible to create or edit a release using the UI https://gitlab.com/gitlab-org/gitlab-ce/issues/56026
Out of scope
Evidence collection for Releases MVC https://gitlab.com/gitlab-org/gitlab-ce/issues/56030 is not scoped in this solution validation.
- A prototype (low- or high-fidelity screenshots or an interactive UI prototype) that covers changes for Releases in %12.4.
- gitlab-ce~2024184 @rverissimo
- gitlab-ce~10831579 @ogolowinski
- gitlab-ce~3412464 @nfriend
- gitlab-ce~2492649 @ebaque
|Theme||Description||Problem it solves||Possible user stories|
|Notifications||Subscribe to content and receive notifications on changes.||Not getting information in a timely manner. Not sure if anything being release if not notified.||Notifications are conditional. Notify user if a new release is fired off. Notify only if the user subscribes manually.|
|Create||Create and edit a Release.||Not being able to manage releases via UI. Having to either manage a Release using the command line (using curl), or a GUI application.||User can create/edit a release via UI. Only users with the necessary rights can create/manage a release. System should provide a confirmation of changes.|
|Dashboard||Track status of a Release.||People have visibility of how a Release is doing. View issues status and count.||Release entries are created from Tags. It should be possible to add milestones to a release. Generic enough information so users can track the health status if a Release.|
As a user, I want to subscribe to updates about new releases in a project, so that I'm notified about new versions even for projects I'm not part of.
- Anyone who has access to view the releases page should be able to subscribe to new releases; they could do this "manually" by looking every day.
- Users should be able to subscribe to a release via project home page, and the Releases page.
- Users that don't have disclosure/access to a project should not be able to subscribe to releases.
Subscribe to Releasesoptions should be added to the
Custom notification eventsmodal.
- How important is the
subscribe to releaseoption? Do we display it at a glance in the dropdown option, or hide it in the
As a user, I want to create/edit a Release using the application UI, so that I can have a faster method to quickly manage Releases instead of sending a curl to the GitLab API.
- User should be able to edit an existing Release through the overview page. If user has no access rights to manage a create/release, the option should not be available.
- All options from the
Create tagform should be available when editing an existing release.
- All form items should be pre-populated when user clicks to edit an existing release.
- User should be able to remove a release via UI.
- What type of access rights a user needs to create/edit a release via UI? We need to hide the option if the user has no disclosure/access to the functionality.
- Do we allow users to delete a release from the UI (based on the Tags page)?
- Is it possible to create a release/tag from a specific commit? Do we want to make that available?
- When the user adds a message to the tag using the UI, do we create an annotated tag?
- What consequences editing an existing Release will have for the existing tag?
As a user, I want to see the total number of issues (open and closed) in a release that is linked to milestones, so that I can quickly see how the Release is going.
- Show the total issues, # of issues closed, # of open issues, and % as completion metric on releases page, for all combined associated milestone in a Release.
- User should be able to go to a page to see the issues attached to a release/milestone.
- If no milestone is added to a release, the issues counter should not be displayed.
- Do we want to show the countdown of total issues, for all milestones, or is it important for the user to know specifically the status of issues per milestones?
- Do we want to allow users to go to the individual list view of issues per milestone, or is it sufficient to display a filtered list with all items? (Note: This is currently not possible, see discussion https://gitlab.com/gitlab-org/gitlab-ce/issues/66986#note_212450022)
- Do we display only the issues countdown for Releases that have milestones associated to it -- Releases with no milestones, won't show the issues/merge requests countdown?
- Do we want to display the count for
merge requestsin the future?