There should be a way to surface "status updates" to a parent sub-epic/epic

Problem to solve

Find a way to surface status updates and notify subscribers or specified group of people.

eventually a need arises to provide “status updates” either to other stakeholders or rolling that up to executives.

Other considerations

In a future iteration, we likely want a way to notify different groups of stakeholders based on the type of update.

Example: Quarterly vs. weekly updates.

Top-initiative quarterly updates for example includes:

  • DRI
  • Sponsor
  • link to team members
  • initiative goal
  • health score
  • exit criteria
  • anticipated quarter to retire
  • supporting material (deck, epic, etc.)
  • highlights
  • lowlights
  • next quarter priorities

However, the e-group sponsor and other relevant stakeholders are notified of weekly updates.

Examples

Manual

Here’s a few examples in which this is precisely what we are facing. The following Epics are all of CEO interest and we need to provide weekly updates to Sid:

  1. &8331 (latest update there) (and in particular right now we are updating on Iterations 1A and 1B so now the updates are done at the sub-epic level and we need to click through to this sub-epic to see status.
    1. Would be great at the parent epic level to be able to pull in a summary of the status for each sub-epic.
    2. Idea: each epic has a “status” section where we can post an update. Can have a few fixed elements (e.g., on track, off track, etc. and/or % completions). Then those elements can be referenced/pulled into another epic or issue. We now have the ability to add + at the end of a URL to pull in the title of an issue, I imagine being able to do something similar to pull in the “Status” of an epic.
  2. Similarly, Sid cares about https://gitlab.com/groups/gitlab-org/-/epics/8905, which then got broken down into iterations 1-3. A way to make updates like this structured and pull in some key points to the parent epic would be great.
    1. BTW, I’m hoping to use more the health status aggregations, those are neat, though right now it’s hard to tell how to read those holistically since very few issues have a health status out of the total (e.g., 2 of 5 open issues)

See also leading cross-initiatives MR.

Automation/tools

  1. Enterprise Apps previously built Rolly though I'm not sure if this is still an active project (lead developer left the company) https://about.gitlab.com/handbook/business-technology/how-we-work/rolly/
  2. Ops has also built some light CI automation based off labels for this. @Sam Goldstein https://about.gitlab.com/handbook/engineering/development/ops/#async-updates-no-status-in-meetings https://gitlab.com/gitlab-com/ops-sub-department/ops-status-updates/-/issues
  3. https://gitlab.com/gitlab-org/secure/pocs/discussion-automation
  4. @ipedowitz documented this status update process for his initiative https://internal-handbook.gitlab.io/handbook/product/saas-efficiency/direction/?search=dedicated#status-updates. This uses the GitLab bot in Product project to automate the main issue generation. Moving that bot to a different project requires manual customization.
    • @ipedowitz - the part that I use automation for is the main issue I use to coordinate these manual pings/collation of updates. This generates an issue, such as this one: https://gitlab.com/gitlab-com/Product/-/issues/5123. The automation lives in https://gitlab.com/gitlab-com/Product and the code is here: https://gitlab.com/gitlab-com/Product/-/blob/main/create_issues.rb. @brhea is now the maintainer of this since Kenny left, but I've recently contributed some MRs to enhance the automation to allow for some further customizations. I think a nice enhancement to this automation would be to allow the bot to file issues in different projects than the Product one, this way we wouldn't need to fork and modify the automation in other projects. Perhaps we can promote it from Product to another project if this feature were to be possible? Even with the automated generation of my main issue, it's still a nearly fully manual process to request updates and the collate them. I'd be supportive of some sort of "status" field which could be bubbled up to the parent epic(s). I think there's cases where we'd want the roll-up to go to the first parent epic, and other cases where we'd want it to rollup to the ultimate parent epics (in the case of sub-epics). Would love to see how that could be factored into consideration here.
  5. https://gitlab.com/gitlab-com/gl-infra/epic-issue-summaries
  6. played around with hugo archetype templates in the internal handbook for CoST team updates. see the template here: https://gitlab.com/internal-handbook/internal-handbook.gitlab.io/-/blob/main/content/news/team-updates/ceo-cost/fy22-q3.md?plain=1 . Running [a command] creates a new file and renders the go template to populate things like the table of team members

Original Slack thread

Slack thread for context: https://gitlab.slack.com/archives/C0NFPSFA8/p1669823968482769 (internal only)

Screenshots image image image image image
Edited by Ian Pedowitz