Thanks for the tag here @cbalane - I'll take a look through them this week and add additional feedback around how many I believe are reasonable to schedule into 15.4 given that some may need additional validation.
@rayana - Just to confirm, by the start of this milestone (15.4) I should be taking over all issue work correct? In which case we should only looking to be scheduling issues I can finish up, not the both of us. Are any of these issues currently being worked on?
@cbalane@rayana - Adding in some context from our sync discussion today around the 15.4 UX Plan:
Capacity:
I'll be away for a portion of 15.4 (9 days at the end of the milestone), but am planning to start some of these issues about a week earlier in 15.3. This should mean my capacity is only reduced by 4 days. As an FYI my full PTO spans from September 6th to 20th.
I am still trying to figure out my appropriate capacity for release work, so bare with me for the next milestone or two.
Good to prioritize:
The following issues will be worked on collectively as one larger initiative in the milestone. They will be my first priority to get to, which I may start slightly earlier than 15.4:
As a side note - I will go through each issue and add in weights this afternoon, as well as create the research issue for validating how users want to be notified about pending approvals.
We'll be starting on research initiative on how users would like to be notified about pending approvals. The results of this will drive the solution for Inform users of pending deployment approval
The issue you linked to has a defined user problem and user experience goal. Do you see this problem as something we still need to explore further? Or is this a case where we know enough to start testing out a proposed solution?
Either way, when you draft up a research issue, tag me on it, so we can discuss next steps.
The research effort I was interested in was seeing if todo's would be the ideal way of notifying users of the pending approval, or if this would just create more noise. Is there some other method they would prefer? I think the problem is valid, people need a way to be notified that there are pending approvals. Its the method of notifying I don't think has been fully flushed out (though I may be missing something here so feel free to add more context).
@cbalane - Sounds great! I originally had Provide a mechanism to clean up stale environments as a stretch goal, which I would get to if I had time, but as I'm just planning out my capacity for the first time I want to be cautious not to over-commit. I'll go ahead and break down the ones without weights today and then we should be good to go
The research effort I was interested in was seeing if todo's would be the ideal way of notifying users of the pending approval, or if this would just create more noise.
This sounds like a solution validation study to me since you'll be testing out a proposed idea to tackle the problem. Do you agree?
FYI @wleidheiser@cbalane - There seems to be a workshop coming up about notifications, which I plan to bring our pending deployment approval problem to. This might directly overlap with some of the research I was planning to do around how users want to be notified.
I'll keep you all updated, but thought I would just surface it so you knew
@emilybauman thanks for letting us know, that does sound timely. looking forward to hearing how it goes and making progress on our use case for deployment approvals!
@cbalane thanks for working on this! I've removed all of the issues that we already pulled into 15.3, so now it is pretty clear that we will need to add more items to this milestone. I removed a few other items (details below).
If we can get these refined and weighted in the next few days, then we can add them back. But I wanted to make sure this issue was reflecting what is currently ready for scheduling.
@nicolewilliams thank you for updating and making sure it reflects what is ready for scheduling. and yes, I've responded to Kenny. I'll do another pass at this issue today/tomorrow and update priorities.
I'd like to add https://gitlab.com/gitlab-data/analytics/-/issues/13425+ and pair with someone from the team to help me investigate. it would help solve a customer problem and also lead to a better overall understanding of our key metrics
@gitlab-org/ci-cd/release-group team, sorry for the late ping here, please see this plan for the next milestone. let me know if you have any feedback or questions!
@cbalane - Great issue, and I really appreciate your prioritization rationale. I have to ask what is driving the dogfooding of releases to include Release Post content to your highest priority? I'll state it plainly, the Release group is one of our core investments for extending our lead in CI/CD and while I can appreciate that it would be great to dogfood our Releases capability for the Release Post I would expect the owners of that process to figure out the automation required to do so, not the Release group itself. FYI @fseifoddini@brhea
@kencjohnston thanks for the review and feedback! And apologies for the delayed response, I missed this ping/thread among the others in this issue.
what is driving the dogfooding of releases to include Release Post content to your highest priority?
In short, it's not actually our highest priority and we’'ll be updating the prioritized list of issues to reflect that as we finalize the milestone plan. We have other initiatives (deployment approval, environment search, connecting to other stages, group environments) that are at the top of the list; issues that are ready for dev related to those will be higher in priority than the Release post iterations.
For more context, Brian and Farnoosh and I have been discussing what ways Releases (the feature) can be more of the SSOT for the existing content Release Post content. We have synced a few times in the past few months to discuss a possible way to enhance the feature to meet their needs. I'm confident in and support the vision for enhancing Releases to include tools to assist with Release notes type of content. However, some changes/iterations as requested are GitLab specific and not as applicable to the broader user (Farnoosh, Brian and I have discussed this). There are some feature requests/suggestions that are aligned with our Releases direction, specifically iterations that improve usability and searchability of the feature. What would actually be helpful and drive the priority higher is if we optimize the iterations such that it helps pressure test our vision for Releases with dogfooding feedback. We also discussed creating an opportunity canvas for a Release notes type of feature to have a way to evaluate and compare the opportunity to others we are working on, which I will do.
For now, we'll definitely continue to prioritize the enhancements to extend our lead in CI/CD over anything else. But we may be able to help along the way - i.e. extra capacity, low-hanging fruit, direction features are still being designed, etc - while also gaining learnings to push forward the Releases direction. In the medium term (1-2 quarters), after making more progress in Category:Environment Management category, we will start to more holistically prioritize enhancements to the Release feature as part of Category:Release Orchestration to support ~"deployment-direction", including features to improve Releases and release notes.