Skip to content

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.

Scoped issues

Out of scope

Evidence collection for Releases MVC https://gitlab.com/gitlab-org/gitlab-ce/issues/56030 is not scoped in this solution validation.

Outcome

  • A prototype (low- or high-fidelity screenshots or an interactive UI prototype) that covers changes for Releases in %12.4.

Team

Themes

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.

User stories

1. Notifications https://gitlab.com/gitlab-org/gitlab-ce/issues/55974

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.

Acceptance criteria

  • 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.
  • The Subscribe to Releases options should be added to the Custom notification events modal.

Questions

➡ See discussion thread

  • How important is the subscribe to release option? Do we display it at a glance in the dropdown option, or hide it in the custom notifications modal?

2. Create https://gitlab.com/gitlab-org/gitlab-ce/issues/56026

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.

Acceptance criteria

  • 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 tag form 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.

Questions

➡ See discussion thread

  • 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?

3. Dashboard https://gitlab.com/gitlab-org/gitlab-ce/issues/66694

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.

Acceptance criteria

  • 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.

Questions

➡ See discussion thread

  • 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 requests in the future?
Edited by Jason Yavorsky