Which Issues were worked on in the release (linkable)
The status of issues - (closed/not closed)
The date that the release was complete
Was the Release published to customers or an internal version
Type of release - for example major, minor, patch
The latest build identifiers -id, has value, number, deployed by etc.
For this issue, we want to get an overview look at the releases.
User story
As a user, I want to see the number of relevant issues and their statuses in a release that is associated to milestones, so that I can quickly see how the Release is going.
Acceptance criteria
User sees the completion metrics for a particular Release, that is associated to at least 1 milestone.
For public projects, show the sum of public issues. For Private projects, show the sum of total issues. The number of issues should be displayed in a badge counter.
Show the number of open issues.
Show the number of closed issues.
Show a progress bar with a percentage (%) indicator of closed issues.
Hovering the progress bar should display a tooltip that reads: Closed issues
In the first iteration, users will only see the issue counters, but won't be able to interact with it (click and see the listed issues). This needs to be done first in #32632 (closed).
If no milestone is added to a release, the counters should not be displayed, and no information should be rendered in the page.
Update the card to include a header, where the Release title, badge status, and an edit button should be positioned.
Move the sha, tag, time stamp, and user information to the footer of the card.
The area where the summary of metrics is displayed should be built using columns. In the feature, we will add another column for the merge requests counter.
Page view on GitLab
Prototype
Release page
Intended users
Anyone tracking upcoming releases
Product manager
Product Designer
Release Manager
Further details
Use Case 1 a user will want to see at glance the progress of completion in release
Permissions and Security
Viewer should have permission to browse issues in the milestone
Public projects will only show public issue counts and calculations on public issues in project
Private projects will include total issue counts and calculations on total issues in project
Documentation
We will need to add for public projects only public issues are shown
Testing
Public issue count only for public projects, excluding confidential issues in the project
Private projects will count all issues, inclusive of confidential issues
What does success look like, and how can we measure that?
Use Case 2 a user during planning will want to see how many issues within a release are planned
Show # issues, # of issues closed, and % as completion metric on releases page, for each associated milestone next to where we show the link to the milestone.
Are we adding this functionalities with the Developer persona in mind, or the Release manager? I would like to bring the attention to the experience baselines for Releases here gitlab-design#505 (closed) that focus on the Developer persona.
I think we're moving towards a much bigger effort for the Releases page with those small UI changes, and the whole picture is not clear to me. We need to connect the dots otherwise we'll might need to redesign this view for a different persona anytime soon.
@rverissimo Not exactly- it can be one of the metrics for the director dashboard but it is not a high priority one for him/her in my opinion
When I managed a team I wanted to know specific metrics per engineer such as (for a specific moment in time):
How many issues did he/she work on?
How many issues were reopened?
Metrics around the duration of working on issues - we can start with average
The velocity of the team
How many issues were committed vs. delivered
and so on - we can talk about these in the director dashboard issue.
For this issue, we want to get an overview look at the release, Jira shows it like this:
so What you see here is actually all the current releases - its progress(percentage), released/unreleased. How many issues were contained in the release broken into their status
I updated the description.
I have a question, The title on this issue, the title says "show closed status". Is there a different effort to show any status not only closed?
@rverissimo I have a question, The title on this issue, the title says "show closed status". Is there a different effort to show any status not only closed?
@rverissimo The UX attached to the description is confusing - it should really describe the summary #of issue, percent complete etc.
At the moment it just shows the list of issues which seems unrelated to what needs to be presented specifically here - what do you think?
I think clicking on a link of #of issues - should jump to the issue list. If we created # of closed issues as a link it should show only the closed ones etc.
@ogolowinski please refer to #31615 (comment 216704330) for the discussion and input from engineering on this issue. I left a couple of questions there for us to discuss about the solution.
@rverissimo I don't understand the reference to the other conversation.I think the current UX attached to this item is confusing and doesn't show me anything related to this item
@rverissimo LGTM. My only comment is to make sure each display element can scale. For example, what if there are more than 3 milestones for a release? What's the max use case, how is that displayed, etc.?
@vkarnes There's no limit to how many milestones can be associated with a release, but the milestone items (text) will wrap in a new line if the content doesn't fit the container. We are already making use of this approach
@nfriend I just looked at this issue, you may have everything you need for frontend and may not need anything from backend.
Can you please confirm? If so, please let me know and I will unassign myself from this issue. Otherwise, let's see what I can do to provide you with what you need.
@ebaque I don't have any outstanding questions for you at the moment, so I'll go ahead and unassign you.
I may eventually have questions about the best way to go about getting the data to drive the graph and issue/MR counts, but I'll just reassign you at that point in time
Just a bit of feedback with regards to the UI. It's nice, but one suggestion. I would really put the tag name (and possibly the commit sha too) at the top, not at the bottom. The tag name is quite an important piece of information. And if there is a long release notes text, in the current UI screenshots, you need to scroll down to the bottom until you can see the tag. I don't think that's good. It should be readily available at the top, before you have to (potentially) scroll.
We have plans to update the UI again and iterate on it once we tackle #32827 (closed). The goal is to have dedicated entries per Release so we can accommodate not only those items that are no at a glance, but also the closed issues, related MRs, Release assets, search, filtering etc. You can see the MVC here #32827 (closed)
@jmeshell why did you add planning priority? It should be decided on before planning is closed and there are too many MVP items in 12.6. Why do you find this issue higher priority than #9983 (closed) for example?
@ogolowinski - this would be higher priority for the release team as the Verify team has ownership of #9983 (closed) - although I agree, 12.6 likely has too many MVPs so I’ll remove that denotation.
The problem with these counters is that they are very expensive to calculate and differ by user:
the user might have access to see confidential issues, or might not, but the user can be assigned to one particular issue and then the user can see it anyway.
Milestones page is currently very-very slow partially because of this. It's basically N+1 problem when we calculate counters for every milestone separately.
The same problem occurs for releases which basically just aggregate milestones.
There were several attempts to resolve the issue:
original idea was to cache issue counter for milestones: !18579 (closed) , but it just used first user permissions to calculate issue counters. If the first user visiting page had access to confidential issues, then everyone seeing this page will see confidential issues included in the counter too until cache expires.
The second attempt was to just eliminate N+1, but still make very expensive permissions check once for all milestones: !19950 (closed)
The next idea was to separately cache confidential/non-confidential issues, but we have group milestones, and people can have different access level to different projects
After some discussion with @dzaporozhets we landed on the idea of just including public issue counts both on milestones page and releases.
@dzaporozhets :
I would go with "don't include confidential issues at all in these counters"
private projects will be fine, for public projects it will be a known behavior which we can document
I think performance wise it will be the best approach
Since it's a product decision, I'd like to hear the opinion of @jmeshell on that. Does not including confidential issues in these counters for public projects harm user experience much?
@vshushlin - I agree, let's not include confidential issues as they should be excluded since not all can view them. In the documentation we should advise for public projects only public issues will be included. Thanks for checking in!
@jmeshell considering the frontend being in a very good shape and that we finally have a decision on the backend implementation, I'd say it's at least half done, but it may require up to a week to finish
It's in 31289-issue-summary-on-release-be-2, but there is one notable change:
you were receiving open and closed counts before
not it's total and closed
since we were using those 2 methods everywhere.
ping me if you need any help or if you notice any weird behavior(I added caching for those couters, it should be invalidated in all cases, but I might have missed something)
@nfriend if you already started a new branch for these changes, please rebase again, the branch is the same: 31289-issue-summary-on-release-be-2, just skip all the conflicting commits =)
@vshushlin Cool, thanks. I'll likely just wait until 31289-issue-summary-on-release-be-2 is merged into master since this will be spilling into %12.9 anyway.
Taking a look at this issue's description, there seems to be two UX proposals which are almost identical except for two small differences:
The first only includes issue statistics; the second includes statistics about both issues and merge requests
The first does not include any links in the issue statistics section; in the second, the issue/merge request counts are clickable and link to the search page with the appropriate filters applied
@rayana or @jmeshell can you advise which proposal we need to implement in order to close this issue and turn on the feature flag?
If proposal #1 is sufficient, we can release this feature fairly soon (basically as soon as !19937 (merged) is merged and I make a small follow-up frontend MR to account for the API changes as described in my comment above.)
If instead all of the additional features in proposal #2 are required, we'll need to do a few more things:
A new frontend MR to add the merge request statistics section (currently only the issues section is implemented)
A new backend MR to add merge request stats to the API response (currently the API only provides issue_stats)
A new backend MR to add links for each data point in the statistics section:
Link to the issue search page with state=opened
This is already implemented in the current API response as _links.issues_url
Link to the issue search page with state=closed
Link to the merge request search page with state=opened
Link to the merge request search page with state=closed
Link to the merge request search page with state=merged
@vshushlin can you please let us know if the current issue description matches what you are going to deliver on this MR? !21554 (merged) We've been chatting in the MR discussion and I understand the final deliverable will be different from what we included in the scope.
I will need to update this issue description to be the SSOT.
In order to implement this feature, we wanted to make a small sacrifice in security: enable confidential issues to be included in the milestone issue counters regardless of user permissions.
We do that to be able to cache those counters among all users. And it's hard to have 2 separate caches for confidential/not confidential issues as we do for projects because we have group milestones and user might have access to view confidential issues in one project of the group and don't have it for other projects.
The other alternative is to never include those issues in counters, but this inconsistency will be easier to spot for group members.
@vshushlin This is acceptable from a security point of view as with my current understanding this counter does not allow to learn anything about the content of a confidential issue.
Scenarios in which only the number of private objects is exposed, unless it can be used to extract any sensitive information contained in those objects.
For example a report showing that it's possible to see that a certain project has 17 issues even if only 15 are publicly visible would not be accepted
However being able to demonstrate that there are 4 confidential issues with the word "SECRET TOKEN" in them would be a valid report