Suzanne: I'd prefer we don't move anything, but instead create a new, simplified process for the docs: https://gitlab.com/gitlab-org/technical-writing/docs-gitlab-com/-/work_items/623 This new process should mean we don't need to move any of the things below. <hr> Notes from Arty: For anything we want to keep, we need to move the following from `www-gitlab-com` to the appropriate places: 1. YAML/MD release post content files - including https://about.gitlab.com/releases/gitlab-com/ 2. Release item generation (auto generate YAML files from work items) - Runner generates YAML file, see `gitlab-org/ci-cd/runner-tools/runner-release-post-generator` 3. Linting: schema validation, title/description following vale rules 4. Release post MR description template 5. Release post MR generation (puts the release post together) 6. In-app what's new generation (generated from top/primary items) - Images for in-app what's new - duplicate MR to get it into the patch release (required if the new process does not merge the in-app what's new before release is packaged) 7. Retrospective issue 8. Release notes generation (auto create notes for https://gitlab.com/gitlab-org/gitlab/-/releases and gitlab-foss ) 11. RSS feeds (*must have*) see https://gitlab.com/gitlab-org/technical-writing/docs-gitlab-com/-/work_items/637 - https://about.gitlab.com/all-releases.xml - https://about.gitlab.com/breaking-changes.xml - https://about.gitlab.com/security-releases.xml - https://about.gitlab.com/releases.xml (monthly only?) 12. ~Email subscribe on https://about.gitlab.com/releases/categories/releases/~ -- Not moving/supporting this per https://gitlab.com/groups/gitlab-com/marketing/digital-experience/-/work_items/500#note_3237980939 13. Rotations list Considerations: 1. Deprecations/removals 1. Breaking changes 2. Patch releases, see https://gitlab.com/gitlab-org/technical-writing/docs-gitlab-com/-/work_items/636 3. Components blog posts, such as AI gateway. See https://gitlab.com/gitlab-org/technical-writing/docs-gitlab-com/-/merge_requests/2079#note_3238028311 4. [x] Individual YAML files are used for tooling -- issues created 5. Updating content from www-gitlab-com for 18.x and prior posts. Options include: 1. Set up the triage bot to ping the MR author in the www-gitlab-com if they modify one of the relevant files. 2. Set up an automation to auto-open an issue or MR on the docs side when relevant www-gitlab-com files are updated. (This is a bit more work than above option, and may not be worth it for how not-often this happens.) 3. Doing a sync on build, but script it so only new files are pulled. This will add to the pipeline, but should be minimal if we limit it to newly changed files. 4. Remove the old files and point people to the docs site to update. Other: 1. Update handbook 2. Archive Slack channel(s) Possible new process: 1. label/format epics/issues 2. finalize top/primary items > generate what’s new (including images?) from top/primary only > review & merge what's new 3. generate release notes page MR (day before?) > review > merge when package is up {width=894 height=551}