Backport Slack notifications documentation restore to 19.2

Why is this backport needed (background and context)

The Slack notifications page carried removal markings with a remove_date of 2026-05-16. After that date passed, the content was deleted as routine docs maintenance in gitlab-org/gitlab!240909 (merged), and the page was reduced to a stub that redirects to the GitLab for Slack app page.

Removal of the Slack notifications integration itself has since been called off, because there is no clear migration path yet. The integration is still available and still deprecated, with no removal date set, and customers are still advised to move to the GitLab for Slack app. Because the page was removed on the strength of a removal that is no longer happening, the docs no longer match the product for anyone running 19.2 or 19.3.

The removal was reverted for 19.4 in gitlab-org/gitlab!253599 (merged).

Versions changing: 19.2 only. This issue requests approval for 19.2, which is older than the latest stable branch. The 19.3 backport does not need approval, because 19.3 is the current stable release, and it is already open as gitlab-org/gitlab!253615 (merged).

How the documentation will change: The full page content is restored, including the deprecation warning that points readers to the GitLab for Slack app. The remove_date and the removal markings are not restored, so the page will not be deleted again automatically.

Why 19.2 as well as 19.3: GitLab 19.2 and 19.3 both shipped with the page already gutted, so GitLab 19.1 is the last published version that documents an integration customers are still using. Readers on 19.2 who follow a search result or an in-product link land on a page telling them the feature was removed in 19.1, which is wrong.

For context, see the discussion in Slack: https://gitlab.slack.com/archives/C03EZMMCPQX/p1788491133651239?thread_ts=1788469288.696179&cid=C03EZMMCPQX

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:

  • Mention TW Leadership in a comment in this issue and wait for their approval:

    @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. 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.
  2. 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.
  3. 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 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:

    [ ] Run a new pipeline in docs-gitlab-com. Choose the branch name that matches the stable version, for example 19.2 or 19.3.

  • GitLab 17.8 and earlier:

    [ ] Run a new pipeline 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.
  2. Run a new pipeline in gitlab-docs-archives. Choose the branch name that matches the stable version, for example 15.11 or 16.0.
  3. After the pipeline finishes, go to https://archives.docs.gitlab.com and verify that the changes are available for the respective version.
Edited by Brendan Lynch