## Why is this backport needed (background and context) The developer implemented a checkbox that had no effect in 18.9. The feature will only work in 18.9.1 and later. The docs for 18.9 have two issues: - They don't represent the group-level feature. - They make it sound like the feature works in 18.9, and it does not. See the note here: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/223706#note_3092749134 This setting is about collecting AI usage data, so I think we should go back in time and be very specific about the fact that it only works in 18.9.1 and later. Related MRs: - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/223039/diffs - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/223706/diffs <!-- Backporting documentation to older branches is something that should be used rarely. The criteria includes legal issues, emergency security fixes, and fixes to content that might prevent users from upgrading or cause data loss. Maintainers (backend, frontend, docs) can backport changes, usually bug fixes but also important documentation changes, into the latest stable version. To guarantee the [maintenance policy](https://docs.gitlab.com/ee/policy/maintenance.html) is respected, merging to older stable branches is restricted to release managers. --> ## Get the approval of TW Leadership > The person requesting the backport does this step. If the backport is for a version older than the latest stable branch, ask Technical Writing Leadership for approval: - [x] Mention TW Leadership in a comment in this issue and wait for their approval: ```md @gitlab-org/tw-leadership could I get your approval for this documentation backport? ``` ## Create the merge request to backport the change > The person requesting the backport does this step. Requires at least the > Developer role on the project that needs the backport. To backport a change, you will merge your changes into the stable branch of the version where you want the change to occur. 1. [x] Open a merge request with the backport. The MR should target the stable release branch, for example: `16-11-stable-ee` or `17-0-stable-ee`. Link the MR to this issue. 1. [x] If the backport targets the current stable branch, assign to a Technical Writer for review and merge. Usually, the Technical Writer of the [relevant group](https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments). 1. [ ] If the backport targets any branch other than the latest stable branch, assign the MR to a Technical Writer for review. After the TW approves, ask a [release manager](https://about.gitlab.com/community/release-managers/) to review and merge the change. Mention this issue to them and give them all the context they need. For the change to appear in docs.gitlab.com, merging to the stable branch is all you need. For the change to appear under `/help`, the change needs to be part of a GitLab release. The next time a release manager creates a release, they will include the change in the release. ## Deploy the backport change > A member of the Technical Writing team does this step. Usually, the same Technical Writer > who created the merge request. After the change is backported to a stable branch, the Docker image that holds that version's docs needs to be updated: - GitLab 17.9 and later: - [x] Run a [new pipeline](https://gitlab.com/gitlab-org/technical-writing/docs-gitlab-com/-/pipelines/new) in `docs-gitlab-com`. Choose the branch name that matches the stable version, for example `15.11` or `16.0`. - GitLab 17.8 and earlier: - [ ] Run a [new pipeline](https://gitlab.com/gitlab-org/gitlab-docs/-/pipelines/new) in `gitlab-docs`. Choose the branch name that matches the stable version, for example `15.11` or `16.0`. If the backport change was also made to a version other than the last three stable branches, you need to update the docs archives site: 1. [ ] Make sure the Docker images from the previous instructions are built. 1. [ ] Run a [new pipeline](https://gitlab.com/gitlab-org/gitlab-docs-archives/-/pipelines/new) in `gitlab-docs-archives`. Choose the branch name that matches the stable version, for example `15.11` or `16.0`. 1. [ ] After the pipeline finishes, go to <https://archives.docs.gitlab.com> and verify that the changes are available for the respective version.