For this issue, we want to enable visibility into merge requests by including related MRs for a release:
Use Case 2 a user during planning will want to see how many merge requests within a release are planned
Show # merge requests, # of merge requests closed, and % as completion metric on releases page, for each associated milestone next to where we show the link to the milestone.
As a user, I want to see the number of relevant merge requests with their statuses in a release that is associated to milestones, so that I can quickly see how the Release is going.
Acceptance criteria
Users should be able to see listed MRs
Intended users
Anyone tracking upcoming releases
Product manager
Product Designer
Release Manager
Permissions and Security
This should follow all practices and tests for #31289 (closed)
Documentation
We will need to add for public projects only public issues are shown
Availability & Testing
This should follow all practices and tests for #31289 (closed)
What does success look like, and how can we measure that?
Users should be looking at open and closed issues related to a release
Jackie Porterchanged title from Adding the merge request stats to the Release block header section in Release Progress View to Adding the merge request stats to block header section in Release Progress View
changed title from Adding the merge request stats to the Release block header section in Release Progress View to Adding the merge request stats to block header section in Release Progress View
@jmeshell Same comment here as #205295 (comment 336888379) - the changes required are very similar to #205295 (closed), so it might makes sense to wait until after we've converted to GraphQL.
@nicolewilliams We are good to start any backend work for this feature (adding the new data to the GraphQL and/or REST API).
If we only add the data to the GraphQL endpoint, the frontend will be blocked until #214241 (closed) is complete. If we add the data to both GraphQL and the REST endpoint, this issue isn't blocked.
We could probably begin work on the frontend parts immediately, since the code that will need to be updated for this feature doesn't care whether the data comes from GraphQL or REST - but users wouldn't be able to actually see it until #214241 (closed) is delivered.
Sorry, that ended up being a longer explanation than I intended 😅
I created #262667 (closed) and added it as a blocker for this issue, although it's only a partial blocker.
Without #262667 (closed), we could deliver this feature, but it would only show up on the main Releases page; it wouldn't show up on the individual Release page.
After #262667 (closed), this feature will automatically show up on both pages.
These probably should have been on the planning issue @nicolewilliams - I think they were missed because they were blocked for so long and I bumped them to a release::p1
There will be two additional MRs that will need to be opened/merged before this feature can be delivered:
A very small frontend MR to begin using the new GraphQL fields added in !46161 (merged) once it's merged
A medium?-ish backend MR to add MR stats to milestones (similar to the existing issue stats)
This piece of work has potential to be a little more involved, so a real backend engineer will need to take this on 😄 I think @vshushlin originally added the issue stats (in !19937 (merged)), so he may be able to give a better estimation for how much work this will be.
I'll update the weight of this issue to 5 to reflect this new breakdown.
@nfriend I bumped this to %13.7 but can also create a separate issue to instrument backend but I just thought it maybe easier to coordinate in a single issue - Let me know your preference
@jreporter Question about the existing progress bar: right now its value is generated exclusively based on issue counts (closed issues/total issues). Should it remain like this or should it begin taking into account merge request counts as well? (Maybe (closed issues + merged MRs + closed MRs) / (total issues + total MRs)?)
I'm assuming we want to stay consistent with how the milestone page is computing completion percentages? (Which I think is just based on issue counts.)
Issue status: Frontend is 90% complete, but this feature won't ship in this milestone since it requires backend work (see #205349 (comment 436479148)).
@nicolewilliams@jreporter I don't have a strong opinion, so I'm happy to proceed however you both think best, but I would probably lean toward keeping this issue open and tracking future progress against this issue. 🤷 It's nice to have a single issue that describes the feature and all the history/discussion that went into it.
Jackie Porterchanged title from Adding the merge request stats to block header section in Release Progress View to Frontend for adding the merge request stats to block header section in Release Progress View
changed title from Adding the merge request stats to block header section in Release Progress View to Frontend for adding the merge request stats to block header section in Release Progress View