Add latest changes from gitlab-org/gitlab@13-12-stable-eev13.12.0-rc42

4 files changed, 9 insertions, 5 deletions

diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md
index 227923b324e..26a32464041 100644
--- a/doc/development/contributing/index.md
+++ b/doc/development/contributing/index.md
@@ -123,7 +123,7 @@ The general flow of contributing to GitLab is:
 1. [Create a fork](../../user/project/repository/forking_workflow.md#creating-a-fork)
    of GitLab. In some cases, you will want to set up the
    [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit) to
-   [develop against your fork](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/master/doc/index.md#develop-in-your-own-gitlab-fork).
+   [develop against your fork](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/index.md#develop-in-your-own-gitlab-fork).
 1. Make your changes in your fork.
 1. When you're ready, [create a new merge request](../../user/project/merge_requests/creating_merge_requests.md).
 1. In the merge request's description:
@@ -152,7 +152,7 @@ Keep the following in mind when submitting merge requests:
   reviewer will have reservations about the code's overall quality. When there is a reservation,
   the reviewer will inform the author and provide some guidance.
 - Though GitLab generally allows anyone to indicate
-  [approval](../../user/project/merge_requests/merge_request_approvals.md) of merge requests, the
+  [approval](../../user/project/merge_requests/approvals/index.md) of merge requests, the
   maintainer may require [approvals from certain reviewers](../code_review.md#approval-guidelines)
   before merging a merge request.
 - After review, the author may be asked to update the merge request. Once the merge request has been
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index c505b8cf467..dfabeca34ce 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -358,7 +358,7 @@ code snippet right after your description in a new line: `~feature`.
 Please keep feature proposals as small and simple as possible, complex ones
 might be edited to make them small and simple.
 
-Please submit Feature Proposals using the ['Feature Proposal' issue template](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/issue_templates/Feature%20proposal.md) provided on the issue tracker.
+Please submit Feature Proposals using the ['Feature Proposal' issue template](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) provided on the issue tracker.
 
 For changes in the interface, it is helpful to include a mockup. Issues that add to, or change, the interface should
 be given the ~"UX" label. This will allow the UX team to provide input and guidance. You may
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index 32b0ff45847..922bc52773b 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -78,8 +78,7 @@ request is as follows:
 1. If your MR touches code that executes shell commands, reads or opens files, or
    handles paths to files on disk, make sure it adheres to the
    [shell command guidelines](../shell_commands.md)
-1. If your code creates new files on disk please read the
-   [shared files guidelines](../shared_files.md).
+1. If your code needs to handle file storage, see the [uploads documentation](../uploads.md).
 1. If your merge request adds one or more migrations, make sure to execute all
    migrations on a fresh database before the MR is reviewed. If the review leads
    to large changes in the MR, execute the migrations again once the review is complete.
@@ -251,6 +250,8 @@ requirements.
    with any questions.
 1. The new feature does not degrade the user experience of the product.
 
+Contributions do not require approval from the [Product team](https://about.gitlab.com/handbook/product/product-processes/#gitlab-pms-arent-the-arbiters-of-community-contributions).
+
 ## Dependencies
 
 If you add a dependency in GitLab (such as an operating system package) please
diff --git a/doc/development/contributing/style_guides.md b/doc/development/contributing/style_guides.md
index 444a067a780..20e47b501e6 100644
--- a/doc/development/contributing/style_guides.md
+++ b/doc/development/contributing/style_guides.md
@@ -100,6 +100,9 @@ Our codebase style is defined and enforced by [RuboCop](https://github.com/ruboc
 You can check for any offenses locally with `bundle exec rubocop --parallel`.
 On the CI, this is automatically checked by the `static-analysis` jobs.
 
+In addition, you can [integrate RuboCop](../developing_with_solargraph.md) into
+supported IDEs using the [Solargraph](https://github.com/castwide/solargraph) gem.
+
 For RuboCop rules that we have not taken a decision on yet, we follow the
 [Ruby Style Guide](https://github.com/rubocop-hq/ruby-style-guide),
 [Rails Style Guide](https://github.com/rubocop-hq/rails-style-guide), and