Add latest changes from gitlab-org/gitlab@14-6-stable-eev14.6.0-rc42

3 files changed, 9 insertions, 8 deletions

diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md
index fe7dc52d077..ec05f75c709 100644
--- a/doc/development/contributing/index.md
+++ b/doc/development/contributing/index.md
@@ -129,7 +129,7 @@ The general flow of contributing to GitLab is:
 1. In the merge request's description:
    - Ensure you provide complete and accurate information.
    - Review the provided checklist.
-1. Assign the merge request (if possible) to, or [mention](../../user/project/issues/issue_data_and_actions.md#mentions),
+1. Assign the merge request (if possible) to, or [mention](../../user/discussions/index.md#mentions),
    one of the [code owners](../../user/project/code_owners.md) for the relevant project,
    and explain that you are ready for review.
 
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index 82fd62d8d79..cc6997e1a20 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -100,7 +100,7 @@ request is as follows:
    There isn't a way to know anything about our customers' data on their
    [self-managed instances](../../subscriptions/self_managed/index.md), so keep
    that in mind for any data implications with your merge request.
-   
+
 1. Merge requests **must** adhere to the [merge request performance guidelines](../merge_request_performance_guidelines.md).
 1. For tests that use Capybara, read
    [how to write reliable, asynchronous integration tests](https://thoughtbot.com/blog/write-reliable-asynchronous-integration-tests-with-capybara).
diff --git a/doc/development/contributing/style_guides.md b/doc/development/contributing/style_guides.md
index 754e6c7aec6..fdb6e99fdcd 100644
--- a/doc/development/contributing/style_guides.md
+++ b/doc/development/contributing/style_guides.md
@@ -171,7 +171,8 @@ we should track our progress through the exception list.
 
 When auto-generating the `.rubocop_todo.yml` exception list for a particular Cop,
 and more than 15 files are affected, we should add the exception list to
-a different file, `.rubocop_manual_todo.yml`.
+a different file in the directory `.rubocop_todo/`. For example, the configuration for the cop
+`Gitlab/NamespacedClass` is in `.rubocop_todo/gitlab/namespaced_class.yml`.
 
 This ensures that our list isn't mistakenly removed by another auto generation of
 the `.rubocop_todo.yml`. This also allows us greater visibility into the exceptions
@@ -184,19 +185,19 @@ bundle exec rake rubocop:todo:generate
 ```
 
 You can then move the list from the freshly generated `.rubocop_todo.yml` for the Cop being actively
-resolved and place it in the `.rubocop_manual_todo.yml`. In this scenario, do not commit auto generated
-changes to the `.rubocop_todo.yml` as an `exclude limit` that is higher than 15 will make the
-`.rubocop_todo.yml` hard to parse.
+resolved and place it in the directory `.rubocop_todo/`. In this scenario, do not commit
+auto-generated changes to the `.rubocop_todo.yml`, as an `exclude limit` that is higher than 15
+makes the `.rubocop_todo.yml` hard to parse.
 
 ### Reveal existing RuboCop exceptions
 
 To reveal existing RuboCop exceptions in the code that have been excluded via `.rubocop_todo.yml` and
-`.rubocop_manual_todo.yml`, set the environment variable `REVEAL_RUBOCOP_TODO` to `1`.
+`.rubocop_todo/**/*.yml`, set the environment variable `REVEAL_RUBOCOP_TODO` to `1`.
 
 This allows you to reveal existing RuboCop exceptions during your daily work cycle and fix them along the way.
 
 NOTE:
-Permanent `Exclude`s should be defined in `.rubocop.yml` instead of `.rubocop_manual_todo.yml`.
+Define permanent `Exclude`s in `.rubocop.yml` instead of `.rubocop_todo/**/*.yml`.
 
 ## Database migrations