giseldo/neodataset huggingface dataset:
Upgrades notes are not rendered correctly

The content assembly script is not working correctly with the upgrade notes.

In general:

- There's no newline between the items.
- Dashes are not turned into bullet lists (strangely enough, lists work correctly locally [screenshot](/uploads/e8d744b9bdebb3de5c3e5371e4d1d7f9/Screenshot_2022-11-03_at_15-34-46_GitLab_15.5_released_with_GitLab_Cloud_Seed_and_Autocomplete_suggestions.png))

If we take https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/#upgrade for an example, this section was created from three items:

- https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/release_posts/15_5/utilization-minimum-days-automatic-dormant-user-deactivation-setting.yml
- https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/release_posts/15_5/systems-geo-move-container-registry-to-ssf.yml
- https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/release_posts/15_5/systems-geo-proxying-fail-to-find-new-pipeline-refs.yml

The end result though is the following. Notice there's no newline between items and lists are not rendered correctly.

![Screenshot_2022-11-03_at_15-30-19_GitLab_15.5_released_with_GitLab_Cloud_Seed_and_Autocomplete_suggestions](/uploads/06ea18d186f31791eb3f542158c5ad4c/Screenshot_2022-11-03_at_15-30-19_GitLab_15.5_released_with_GitLab_Cloud_Seed_and_Autocomplete_suggestions.png)

Story points: 2.0
Update deprecation and removal content guidelines

## Problem

Right now, we're often treating deprecations like notifications of an incoming removal. But users see a deprecation as a warning that you need to take action, to prevent a breaking change in the future. It's a subtle difference, but important. When they see a deprecation announcement, they expect to be able to do something immediately.

([Original source](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/13399#deprecations-should-be-actionable))

## Proposed solution

We should make it a requirement that all deprecations are actionable. [This list of Stripe's API changes](https://stripe.com/docs/upgrades#api-versions) shows the kind of implementation we should strive for.

Key terms to take note of: `deprecated in favor of`, `removed in favor of`, `use YYY instead`, etc. It is clearly explained what people need to do for each item.

Examples:

* We have removed tax_percent from objects and requests in favor of tax rates.
* Deprecate the payment_method.card_automatically_updated webhook in favor of payment_method.automatically_updated.
* Checkout Sessions no longer include the display_items property. Use the includable line_items property instead.

Then our requirement that breaking changes be announced at least 2-3 milestones before the major milestone means:

* We're *not* giving users 2-3 milestones to *prepare* for the change. We're giving them time to **make** the change.
* It isn't good enough to just make an announcement, we must have the deprecation *action* available at least 2-3 milestones before the breaking change as well. In fact, the deprecation process could be essentially: "Step 1, prepare the replacement, step 2, create the deprecation, Step 3..."

### What is the Action when a replacement isn't provided?

The action would be "Discontinue use of this feature by X.Y."

### An example that we should try to avoid would be:

* Deprecation: Feature A is being removed, to be replaced with a future feature. Action: Wait for the future feature, and switch to it when it becomes available.

In this case, the deprecation should be delayed until the replacement is available.

## How to do it

- [x] Update process documentation
  - [x] Docs https://gitlab.com/gitlab-org/gitlab/-/merge_requests/104449
  - [x] Handbook https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/115169
- [x] Announce updated process and structure examples to Product and TW teams
- [x] Create follow-up steps with TW and ProdOps stakeholders to review adoption https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/14318

Story points: 5.0
Update Recruitment Alignment

#### Updating recruiting alignment page to complete training task and add Jess Dallmar



Here is the link to the current page https://about.gitlab.com/handbook/hiring/recruiting-alignment/. The update is italicized.

## Talent Acquisition Leader Alignment

| Department                    | Leader      | 
|--------------------------|-----------------|
| Talent Acquisition         | Rob Allen | _Jess Dallmar_
| Talent Brand and Enablement | Devin Rogozinski |
| Talent Acquisition (Sales) | Jake Foster|
| Talent Acquisition (Marketing) | Jake Foster / Steph Sarff |
| Talent Acquisition (G&A) | Jake Foster |
| Talent Acquisition (R&D) | Ursela Knezevic |
| Candidate Experience & Enablement | Marissa Ferber |
| Inbound Sourcing | Chris Cruz |

Story points: 1.0
Update Fulfillment handbook page to better describe Slack communications

<!--

This template is for requesting work related to the [company handbook](https://about.gitlab.com/handbook/).

This is not the correct repository for requests related to docs.gitlab.com, the GitLab product, or other items.

You may link to this issue template using the following URL: https://gitlab.com/gitlab-com/www-gitlab-com/issues/new?issuable_template=-handbook-update

-->

#### Briefly describe the update

<!--
Example: Updating team documentation regarding project workflow.
-->
https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/704#note_1122535474

Update the fulfillment page to better describe which slack channels to use for which use cases


<!-- These labels will be automatically applied unless you edit or delete the following section -->

Story points: 1.0
Low engagement on Release post MVP nominations

# Summary

We would like to request some ideas on how to increase the number of MVP nominations we receive on a monthly basis. It's an important component of the release post that gives us a chance to live out our values of Collaboration and Inclusion, but with each milestone, we receive very few nominations and the same contributors are nominated again and again.

## Current process

1. An MVP nomination issue is generated for each release post cycle: [15.2 example](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/13658)
1. The [issue template](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/.gitlab/issue_templates/release-post-mvp-nominations.md) mentions `@gl-product @gitlab-org/coaches @gitlab-com/marketing/community-relations` in order to increase awareness amongst relevant teams
1. The release post manager solicits nominations on the 7th and 12th by sharing a link to the nomination issue in the following Slack channels `#release-post, #community-relations, #mr-coaching #core`
1. The release post manager makes a selection from the nominations on the 15th, or escalates the lack of a nominee in those same channels

## Contributing to this issue

1. Scan the issue to see if your idea has already been contributed
1. Start a thread with a recommendation to increase MVP nominations

@gl-product @gitlab-org/coaches @gitlab-com/marketing/community-relations

Story points: 2.0
Apply `removal_milestone` filter to the Deprecations page via URL parameter

## Problem

Creating the Breaking Changes blog post is challenging to coordinate. It is necessary because it makes it easy for customers to find all the breaking changes in one place without any noise.

## Proposed solution

If the deprecations page could be filtered by removal_milestone and breaking_change in the URL (i.e. `https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=16.0&breaking_change=true`) this URL could then serve as the SSOT for breaking changes instead of a blog post.

We use broadcast messages (and in 16.0, we hope to incorporate email) to direct customers to "See all the Breaking Changes coming in X.Y."

- [x] [Filter by removal milestone](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/2906)
- [ ] Filter by breaking change

## Current limitation

Currently, the filtering UI on the deprecations page does not update the URL when a filter is selected. So, there isn't a way to link to a URL that will automatically apply a filter.

Story points: 1.0
Adding Work Zones to Handbook Scheduling Meetings Page

<!--

This template is for requesting work related to the [company handbook](https://about.gitlab.com/handbook/).

This is not the correct repository for requests related to docs.gitlab.com, the GitLab product, or other items.

You may link to this issue template using the following URL: https://gitlab.com/gitlab-com/www-gitlab-com/issues/new?issuable_template=-handbook-update

-->

#### Briefly describe the update

<!--
Example: Updating team documentation regarding project workflow.
-->
Adding a reference on Handbook page that shows overlaps in different work zones (EMEA/APAC/AMER) which will help when scheduling meetings across multiple work zones. A better definition of "friendly" times across three work zones.


<!-- These labels will be automatically applied unless you edit or delete the following section -->

Story points: 0.0
Application metrics mvc/poc

### What

The intention is to build out a minimal viable product or proof of concept for application metrics within the GitLab project. Artifacts from this effort should be:

- Application metric sent to Prometheus (think code block timing)
- Dashboard showing this metric build on prometheus (aggregated like averages/P95/other?)
- Playbook for other teams showing how to product application metrics and dashboards

The intention is to provide team members with metrics that enable them to performance tune their code.

### Why

Metrics is one component of our tooling that will enable team member efficiency, reduce chances for customer visible outages, and help avoid security and other bugs. More information on this effort can be found here: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/13521

### When

The minimal viable product or proof of concept will ideally be complete before the end of the quarter.

### Questions

- How much effort is involved?
   - This is up to the team who agrees to take on this task. There may be libraries needed, processes, and/or methodologies developed but fundamentally this is more a proof of concept that is functioning - think a roller skate rather than a car wheel.
- Others?

Story points: 2.0
Could we add a "Special Recognitions" content block for Group MVPs, notable contributions, etc.?

Could we add a "Special Recognitions" content block for Group MVPs, notable contributions, etc.?

Following on from [a conversation in Slack](https://gitlab.slack.com/archives/C3TRESYPJ/p1646837064632809?thread_ts=1646759801.045189&cid=C3TRESYPJ):

`@ogolowinski`: "I wonder if we can make a group MVP? Add a new category for community collaboration?"

`@fseifoddini`: "I love the idea of special recognitions content block in the release post, if we wanna discuss in retro or do a proposal issue, regardless."

`@cbacharakis`: "I don't see a reason for not having more than one MVP, especially in this case where everyone worked together towards the same goal. It also encourages people to work together as pairs/teams which increases the sense of ownership and collaboration."

@ogolowinski @cbacharakis @sam.white @johncoghlan @NicoleSchwartz @fseifoddini What are the merits of adding a "Special Recognition" section to the template versus modifying the code and process to allow for multiple MVPs in a given release?

For what it's worth, modifying the template to allow for multiple MVP entries in a release would be trivial.

Story points: 3.0
Release Post Item generator is creating MRs for deprecations and removals in the wrong repo

### Description

For context: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/84700#note_837950452

Since deprecations and removals used to be release blog post items, the generator creates MRs in `www-gitlab-com` if an Issue matches any `release post item::` label.

Which includes ~"release post item::deprecation" and ~"release post item::removal"

### Challenge

These MRs are now noisy because we've updated the deprecations and removals process.

Deprecation and removal MRs are now created in the `gitlab` project and compiled directly into GitLab Docs.

### Proposal

- [ ] Tweak the generator so that it only creates MRs for ~"release post item" Issues and Epics that are not ~"release post item::deprecation" or ~"release post item::removal"

### Nice to have

- [ ] Create the MR in the `gitlab` project following [the updated process](https://about.gitlab.com/handbook/marketing/blog/release-posts/#deprecations)

Story points: 1.0
Perform release post content assembly with a bot

### Summary

[Content assembly: merging release post items (content blocks) to your branch](https://about.gitlab.com/handbook/marketing/blog/release-posts/#content-assembly-merging-release-post-items-content-blocks-to-your-branch) could be run on a regular basis by a Bot. The RPM's responsibility would be to check the branch for issues rather than running the assembly themselves.

### Proposal

**Option A: Simple**

Create a job that runs the once nightly, where `X-Y` is the active milestone.

```
  git checkout master
  git pull
  git checkout release-X-Y
  git pull
  git merge master
  bin/release-post-assemble
  git push
  git push origin release-X-Y
```

**Option B: [Specific](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/12865#note_820269872)**

> I think that a commit should queue a pipeline that checks if the branch name matches the release post naming convention (e.g. release-x-y). If the branch matches that naming convention run the content assembly script for every commit. If the pipeline fails, email the committer that their commit needs to be fixed (or better yet, slack them).

Related: https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/12865#note_815576374

Story points: 2.0
Document prioritization sessions in handbook

<!--

This template is for requesting work related to the [company handbook](https://about.gitlab.com/handbook/).

This is not the correct repository for requests related to docs.gitlab.com, the GitLab product, or other items.

You may link to this issue template using the following URL: https://gitlab.com/gitlab-com/www-gitlab-com/issues/new?issuable_template=-handbook-update

-->

#### Briefly describe the update

Document prioritization sessions in handbook, a planning tool in times of uncertainty and lack of direction.

Link from/to:
- https://about.gitlab.com/handbook/product-development-flow/
- https://about.gitlab.com/handbook/product/product-processes/#using-the-rice-framework

<!-- These labels will be automatically applied unless you edit or delete the following section -->

Story points: 1.0
Link from UX handbook to guidelines on discussing competitors in public

The following discussion from !94038 should be addressed:

- [ ] @pedroms started a [discussion](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/94038#note_740219469):  (+4 comments)

    > these kinds of discussions are not specific to Product Designers or other members of the UX department. I frequently witness Product Managers engaging in similar discussions and sharing competitor features. I wonder if there's a more generic location for this? Maybe as a sub-page of our SAFE guidelines?

## Proposal

> I'm thinking the [UX Department “How we work” page](https://about.gitlab.com/handbook/engineering/ux/how-we-work/) might be a good place to link to these new guidelines.

Story points: 1.0
Fix Timeout Issue Estimated cost of Abuse KPI

https://app.periscopedata.com/app/gitlab/780726/WIP:-Blocked-User-Usage-Data?widget=12404680&udv=0 sometimes times out because the query takes too long, need to optimize it.

Look at using monthly table instead of `legacy.gitlab_dotcom_project_statistic_snapshots_daily` to reduce time

Story points: 3.0
create corrective action charts

From slack
> @dawsmith  
thanks @meks - adding @amoter  who was looking to do some more estimates on arrival/close rates

> Right now we have https://app.periscopedata.com/app/gitlab/787921/Corrective-Actions showing the cumulative overdue corrective actions over time.  I think we were looking to add a daily or weekly arrival/close graph of corrective actions

Add charts for:

- [x] how many new infrastructure CAs were created in a week
  - https://app.periscopedata.com/app/gitlab/787921/Corrective-Actions---Infrastructure?widget=12802448&udv=0
- [x] how many infrastructure CAs were closed in a week
  - https://app.periscopedata.com/app/gitlab/787921/Corrective-Actions---Infrastructure?widget=12802466&udv=0
- [x] if possible, broken down by sev/priority levels
- [x] of the closed, how many have the label "workflow-infra::cancelled" and how many have the label "workflow-infra::done"
  - https://app.periscopedata.com/app/gitlab/787921/Corrective-Actions---Infrastructure?widget=12845002&udv=0

## UPDATE
Corrective actions dashboard & KPI logic changed to only include corrective actions under [Infrastructure project](https://gitlab.com/gitlab-com/gl-infra/infrastructure)

Story points: 1.0
Add/hide blog tags

I'd like to add a tag to the blog tags/categories:


DevOps Platform

Here are associated posts you can use to queue this up:

https://about.gitlab.com/blog/2021/09/03/the-code-review-struggle-is-real-heres-what-you-need-to-know/
https://about.gitlab.com/blog/2021/09/02/the-journey-to-a-devops-platform/
https://about.gitlab.com/blog/2021/08/03/welcome-to-the-devops-platform-era/
https://about.gitlab.com/blog/2021/06/22/gitlab-14-modern-devops/
https://about.gitlab.com/blog/2021/05/19/agile-planning-with-a-devops-platform/

And I'd like to make

Unfiltered

invisible, if that's possible. Thanks much!

Story points: 1.0
Stacked MR Chart based on group

I'd like to see a stacked chart based on group for MRs.  

Ideally I'd either have filter capability for the type of MR (feature, bug, etc.) OR I can also just have it for feature MRs.  

It may end up being a performance indicator, but right now I need it to assess how our product investment is going and which teams are still doing feature work.

Story points: 1.0
Ensure accuracy of group->stage-> section label

Currently snippets pull

- group -> group (group label)
  - Snippet: https://app.periscopedata.com/app/gitlab/snippet/select_group_name_from_label/5563886fad9b48bb857880de1e7cd019/edit

- stage -> stage (devops label)
  - Snippet: https://app.periscopedata.com/app/gitlab/snippet/select_stage_from_label/554ade7075c54af092bb6075603302d2/edit

- stage -> section (section label)
  - Snippet: https://app.periscopedata.com/app/gitlab/snippet/development_section_by_stage_label/55b957e9630748308ed9c61b09707b86/edit


Long term we should create a sheetload or mapping table that has group -> stage-> section

cc @kwiebers @lmai1 @meks

Story points: 3.0
Create Dimensional Model to support MR metrics

Create fact/dim/mart tables to support current & future MR metrics to make queries faster & add more of the logic in dbt modeling layer

Final table should include fields needed for MR based Metrics:
- [ ] is_part_of_product (uses ops & .com data)
- [ ] daily history of MRs with state at each day (merged vs open)
- [ ]

Story points: 8.0
Create Dimensional Model Tables to support Issue Metrics and improve rendering performance

Create Dimensional Models to support end fact/mart table that will support all the issue metrics we use, especially "Open Age" Metrics & Label based metrics

See https://gitlab.com/gitlab-data/analytics/-/merge_requests/5251 for example of how to do this

Final Table should include
- [x] historical dates by day of issues & state at that time (open v closed)
- [ ] common labels with correct valid dates (ex. sev 2 from Jan 1 2020 -> Jan 3, then Sev 3 afterwards
  - see corrective actions snippet for guidance
  - [x] Severity Labels
  - [ ] Priority Labels
  - [ ] section/stage/group labels
  - [ ] Incident labels (is_incident)
- [x] full label array included
- [x] issue age
- [x] issue age since severity label was added
- [x] full linkable issue URL
- [x] array of assigned users

Story points: 8.0
Follow-up from "add ytTracker.digestPotentialVideos() to video modal"

The following discussion from !86913 should be addressed:

- [ ] @laurenbarker started a [discussion](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/86913#note_635786114):  (+5 comments)

    > @@dennis106 ping me when we're ready to deploy this MR. Thanks!

Story points: 1.0
Refresh query for Incident Root Cause

I suspect that we're not querying the right data, probably due to the recent change to Incident Issue type?

https://app.periscopedata.com/app/gitlab/793517/Infrastructure-Incident-Data?widget=10637568&udv=1311208

What I note is that the July number of incidents is way down (inconsistent with our real incident count), and doesn't show any root cause info

Story points: 1.0
Investigate Long Loading Time of PI Pages

Stakeholders have brought up the long loading times of the PI Pages as an issue.

Examples:

* https://about.gitlab.com/handbook/engineering/infrastructure/performance-indicators/
* https://about.gitlab.com/handbook/engineering/development/performance-indicators/

We should investigate if this mainly a problem with the query times of the PIs or with rendering time of the charts

If the issue is rendering time, will probably need help from others to improve that, but if the issue the queries we can improve that load time by optimizing the longest running queries, & eliminating excess PI charts


## Ideas 

### Backend performance

* @davis is currently looking into query performance
* Davis: Looked at query times of the underlying performance. Have processing be done at Snowflake. 

### Frontend performance

* Render only KPIs Don’t render charts for (Regular) RPIs, requiring a click thru to Sisense instead
* Lazy load RPIs on scroll
* Only render RPIs in a popup/modal if someone mouses-over an icon
* Other?

cc @edjdev

Story points: 3.0
August 2021 Key Review PI Prep

Items to review/change before August 2021 Key Meeting:

- [ ] Looking to have handbook PI page as storyboard approach, order KPI/PI in order that makes most sense (most-> least important for department head or other logical ordering)
- [ ]  add DRI attribute to PIs?
- [x] Write Comments on KPI changes
  - [x] correcting data to reflect more accurate total cost for hosting with removal of the one time credits & offsets
  - [x] introduced PI for % of labeled spend for cost visibility

- [x]  make overview video
  -> include DRIs in video for updates?

Story points: 3.0
Update Availability graph - June 2021 data

The observability issue we were seeing last week in relation to the last month reporting for Availability has been resolved.

June availability was 99.84%
https://dashboards.gitlab.net/d/general-slas/general-slas?orgId=1&from=now-1M%2FM&to=now-1M%2FM

Please update this in the availability csv and reflect it in the chart. I don't seem to have perms to do this after the changes to get the 2 decimal points showing.

Also, the display on https://about.gitlab.com/handbook/engineering/infrastructure/performance-indicators/#gitlabcom-availability only shows to March, even though the April and May data should already be in the csv.

Story points: 1.0
SecAuto OKR/epic progress PI change

- Does OKR progress need to be tracked as PI? already tracked as a OKR in Ally right?
- For epics, I don't think this fits in as a PI since epics are constantly being opened so would never reach 100% target. 
- I would suggest removing this altogether as a PI, but keep dashboard for tracking if want to see that view
  - Other KPi/PI should represent goals of the department, PIs represent tracking towards those goals, & epics will represent progress towards those metrics/goals. So a PI for epic progress is redundant

Story points: 1.0