Create new section for content about feature that might confuse users

Also do some light editing of page

data/deprecations/15-9-required-pipeline-configuration.yml

@@ -9,9 +9,10 @@
   stage: Verify  # (required) String value of the stage that the feature was created in. e.g., Growth
   issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/389467  # (required) Link to the deprecation issue in GitLab
   body: |  # (required) Do not modify this line, instead modify the lines below.
-    Required Pipeline Configuration will be removed in the 16.0 release. This impacts Self-Managed users on the Ultimate license.
+    Required Pipeline Configuration will be removed in the 16.0 release. This impacts self-managed users on the Ultimate license.
 
-    We recommend replacing this with an alternative [compliance solution](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#configure-a-compliance-pipeline) that is available now. We recommend this alternative solution because it provides greater flexibility, allowing required pipelines to be assigned to specific compliance framework labels.
+    We recommend replacing this with an alternative [compliance solution](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#compliance-pipelines)
+    that is available now. We recommend this alternative solution because it provides greater flexibility, allowing required pipelines to be assigned to specific compliance framework labels.
 #
 # OPTIONAL END OF SUPPORT FIELDS
 #

doc/administration/compliance.md

@@ -50,7 +50,7 @@ compliance:
 
 - [**Compliance frameworks**](../user/group/compliance_frameworks.md) (for groups): Create a custom
   compliance framework at the group level to describe the type of compliance requirements any child project needs to follow.
-- [**Compliance pipelines**](../user/group/compliance_frameworks.md#configure-a-compliance-pipeline) (for groups): Define a
+- [**Compliance pipelines**](../user/group/compliance_frameworks.md#compliance-pipelines) (for groups): Define a
   pipeline configuration to run for any projects with a given compliance framework.
 
 ## Audit management

doc/ci/yaml/index.md

@@ -374,7 +374,7 @@ start. Jobs in the current stage are not stopped and continue to run.
 
 - If a job does not specify a [`stage`](#stage), the job is assigned the `test` stage.
 - If a stage is defined but no jobs use it, the stage is not visible in the pipeline,
-  which can help [compliance pipeline configurations](../../user/group/compliance_frameworks.md#configure-a-compliance-pipeline):
+  which can help [compliance pipeline configurations](../../user/group/compliance_frameworks.md#compliance-pipelines):
   - Stages can be defined in the compliance configuration but remain hidden if not used.
   - The defined stages become visible when developers use them in job definitions.
 

doc/update/deprecations.md

@@ -239,9 +239,10 @@ WARNING:
 This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
 Review the details carefully before upgrading.
 
-Required Pipeline Configuration will be removed in the 16.0 release. This impacts Self-Managed users on the Ultimate license.
+Required Pipeline Configuration will be removed in the 16.0 release. This impacts self-managed users on the Ultimate license.
 
-We recommend replacing this with an alternative [compliance solution](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#configure-a-compliance-pipeline) that is available now. We recommend this alternative solution because it provides greater flexibility, allowing required pipelines to be assigned to specific compliance framework labels.
+We recommend replacing this with an alternative [compliance solution](https://docs.gitlab.com/ee/user/group/compliance_frameworks.html#compliance-pipelines)
+that is available now. We recommend this alternative solution because it provides greater flexibility, allowing required pipelines to be assigned to specific compliance framework labels.
 
 </div>
 

doc/user/admin_area/settings/continuous_integration.md

@@ -247,7 +247,7 @@ To enable or disable the banner:
 > [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/352316) from GitLab Premium to GitLab Ultimate in 15.0.
 
 NOTE:
-An alternative [compliance solution](../../group/compliance_frameworks.md#configure-a-compliance-pipeline)
+An alternative [compliance solution](../../group/compliance_frameworks.md#compliance-pipelines)
 is available. We recommend this alternative solution because it provides greater flexibility,
 allowing required pipelines to be assigned to specific compliance framework labels.
 

doc/user/application_security/get-started-security.md

@@ -37,7 +37,7 @@ The following steps help you get the most from GitLab application security tools
    remediating existing vulnerabilities and preventing the introduction of new ones.
 1. Enable other scan types such as [SAST](sast/index.md), [DAST](dast/index.md),
    [Fuzz testing](coverage_fuzzing/index.md), or [Container Scanning](container_scanning/index.md).
-1. Use [Compliance Pipelines](../group/compliance_frameworks.md#configure-a-compliance-pipeline)
+1. Use [Compliance Pipelines](../group/compliance_frameworks.md#compliance-pipelines)
    or [Scan Execution Policies](policies/scan-execution-policies.md) to enforce required scan types
    and ensure separation of duties between security and engineering.
 1. Consider enabling [Review Apps](../../development/testing_guide/review_apps.md) to allow for DAST

doc/user/application_security/index.md

@@ -487,7 +487,7 @@ Security and compliance teams must ensure that security scans:
 
 GitLab provides two methods of accomplishing this, each with advantages and disadvantages.
 
-- [Compliance framework pipelines](../group/compliance_frameworks.md#configure-a-compliance-pipeline)
+- [Compliance framework pipelines](../group/compliance_frameworks.md#compliance-pipelines)
   are recommended when:
 
   - Scan execution enforcement is required for any scanner that uses a GitLab template, such as SAST IaC, DAST, Dependency Scanning,

doc/user/application_security/policies/scan-execution-policies.md

@@ -17,7 +17,7 @@ of a job name collision, GitLab adds a dash and a number to the job name. GitLab
 no longer conflicts with existing job names. If you create a policy at the group level, it applies to every child project
 or subgroup. You cannot edit a group-level policy from a child project or subgroup.
 
-This feature has some overlap with [compliance framework pipelines](../../group/compliance_frameworks.md#configure-a-compliance-pipeline),
+This feature has some overlap with [compliance framework pipelines](../../group/compliance_frameworks.md#compliance-pipelines),
 as we have not [unified the user experience for these two features](https://gitlab.com/groups/gitlab-org/-/epics/7312).
 For details on the similarities and differences between these features, see
 [Enforce scan execution](../index.md#enforce-scan-execution).

doc/user/group/compliance_frameworks.md

@@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 You can create a compliance framework that is a label to identify that your project has certain compliance
 requirements or needs additional oversight. The label can optionally enforce
-[compliance pipeline configuration](#configure-a-compliance-pipeline) to the projects on which it is
+[compliance pipeline configuration](#compliance-pipelines) to the projects on which it is
 [applied](../project/settings/index.md#add-a-compliance-framework-to-a-project).
 
 Compliance frameworks are created on top-level groups. Group owners can create, edit, and delete compliance frameworks:
@@ -87,7 +87,7 @@ mutation {
 }
 ```
 
-## Configure a compliance pipeline **(ULTIMATE)**
+## Compliance pipelines **(ULTIMATE)**
 
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3156) in GitLab 13.9, disabled behind `ff_evaluate_group_level_compliance_pipeline` [feature flag](../../administration/feature_flags.md).
 > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/300324) in GitLab 13.11.
@@ -106,11 +106,18 @@ However, the compliance pipeline configuration can reference the `.gitlab-ci.yml
 See [example configuration](#example-configuration) for help configuring a compliance pipeline that runs jobs from
 labeled project pipeline configuration.
 
-Be aware that users have no way of knowing that a compliance pipeline has been configured and might be confused
-why their own pipelines are not running at all, or include jobs that they did not define themselves. When authoring
-pipelines on a labeled project, there is no indication that a compliance pipeline has been configured. The only marker
-at the project level is the compliance framework label itself, but the label does not say whether the framework has a
-compliance pipeline configured or not.
+### Effect on labeled projects
+
+Users have no way of knowing that a compliance pipeline has been configured and might be confused why their own
+pipelines are not running at all, or include jobs that they did not define themselves.
+
+When authoring pipelines on a labeled project, there is no indication that a compliance pipeline has been configured.
+The only marker at the project level is the compliance framework label itself, but the label does not say whether the
+framework has a compliance pipeline configured or not.
+
+Therefore, communicate with project users about compliance pipeline configuration to reduce uncertainty and confusion.
+
+### Configure a compliance pipeline
 
 To configure a compliance pipeline:
 
@@ -211,10 +218,10 @@ include:  # Execute individual project's configuration (if project contains .git
 The `rules` configuration in the `include` definition avoids circular inclusion in case the compliance pipeline must be able to run in the host project itself.
 You can leave it out if your compliance pipeline only ever runs in labeled projects.
 
-#### CF pipelines in Merge Requests originating in project forks
+#### Compliance pipelines in merge requests originating in project forks
 
-When an MR originates in a fork, the branch to be merged usually only exists in the fork.
-When creating such an MR against a project with CF pipelines, the above snippet fails with a
+When a merge request originates in a fork, the branch to be merged usually only exists in the fork.
+When creating such a merge request against a project with compliance pipelines, the above snippet fails with a
 `Project <project-name> reference <branch-name> does not exist!` error message.
 This error occurs because in the context of the target project, `$CI_COMMIT_REF_NAME` evaluates to a non-existing
 branch name.