Add latest changes from gitlab-org/gitlab@13-10-stable-eev13.10.0-rc40

3 files changed, 19 insertions, 8 deletions

diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index da38d1e73b4..7029c8a8384 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -149,8 +149,8 @@ and `~"group::knowledge"` is picked up by someone in the Access group of the Pla
 the issue should be relabeled as `~"group::access"` while keeping the original
 `~"devops::create"` unchanged.
 
-We also use stage and group labels to help quantify our [throughput](https://about.gitlab.com/handbook/engineering/management/throughput/).
-Please read [Stage and Group labels in Throughput](https://about.gitlab.com/handbook/engineering/management/throughput/#stage-and-group-labels-in-throughput) for more information on how the labels are used in this context.
+We also use stage and group labels to help measure our [merge request rates](https://about.gitlab.com/handbook/engineering/merge-request-rate/).
+Please read [Stage and Group labels](https://about.gitlab.com/handbook/engineering/metrics/#stage-and-group-labels) for more information on how the labels are used in this context.
 
 ### Category labels
 
@@ -181,7 +181,7 @@ For instance, the "DevOps Report" category is represented by the
 `devops_reports.name` value is "DevOps Reports".
 
 If a category's label doesn't respect this naming convention, it should be specified
-with [the `label` attribute](https://about.gitlab.com/handbook/marketing/website/#category-attributes)
+with [the `label` attribute](https://about.gitlab.com/handbook/marketing/inbound-marketing/digital-experience/website/#category-attributes)
 in <https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml>.
 
 ### Feature labels
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index 166f7b350bf..9051b621bcd 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -68,10 +68,11 @@ request is as follows:
    1. Use the syntax `Solves #XXX`, `Closes #XXX`, or `Refs #XXX` to mention the issue(s) your merge
       request addresses. Referenced issues do not [close automatically](../../user/project/issues/managing_issues.md#closing-issues-automatically).
       You must close them manually once the merge request is merged.
+   1. The MR must include *Before* and *After* screenshots if UI changes are made.
+   1. Include any steps or setup required to ensure reviewers can view the changes you've made (e.g. include any information about feature flags).
 1. If you're allowed to, set a relevant milestone and [labels](issue_workflow.md).
 1. UI changes should use available components from the GitLab Design System,
-   [Pajamas](https://design.gitlab.com/). The MR must include *Before* and
-   *After* screenshots.
+   [Pajamas](https://design.gitlab.com/).
 1. If the MR changes CSS classes, please include the list of affected pages, which
    can be found by running `grep css-class ./app -R`.
 1. If your MR touches code that executes shell commands, reads or opens files, or
diff --git a/doc/development/contributing/style_guides.md b/doc/development/contributing/style_guides.md
index 2a2cfebe964..444a067a780 100644
--- a/doc/development/contributing/style_guides.md
+++ b/doc/development/contributing/style_guides.md
@@ -56,10 +56,10 @@ The current Lefthook configuration can be found in [`lefthook.yml`](https://gitl
 Before you push your changes, Lefthook automatically runs the following checks:
 
 - Danger: Runs a subset of checks that `danger-review` runs on your merge requests.
-- ES lint: Run `yarn eslint` checks (with the [`.eslintrc.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.eslintrc.yml) configuration) on the modified `*.{js,vue}` files. Tags: `frontend`, `style`.
+- ES lint: Run `yarn run lint:eslint` checks (with the [`.eslintrc.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.eslintrc.yml) configuration) on the modified `*.{js,vue}` files. Tags: `frontend`, `style`.
 - HAML lint: Run `bundle exec haml-lint` checks (with the [`.haml-lint.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.haml-lint.yml) configuration) on the modified `*.html.haml` files. Tags: `view`, `haml`, `style`.
 - Markdown lint: Run `yarn markdownlint` checks on the modified `*.md` files. Tags: `documentation`, `style`.
-- SCSS lint: Run `bundle exec scss-lint` checks (with the [`.scss-lint.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.scss-lint.yml) configuration) on the modified `*.scss{,.css}` files. Tags: `stylesheet`, `css`, `style`.
+- SCSS lint: Run `yarn lint:stylelint` checks (with the [`.stylelintrc`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.stylelintrc) configuration) on the modified `*.scss{,.css}` files. Tags: `stylesheet`, `css`, `style`.
 - RuboCop: Run `bundle exec rubocop` checks (with the [`.rubocop.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.rubocop.yml) configuration) on the modified `*.rb` files. Tags: `backend`, `style`.
 - Vale: Run `vale` checks (with the [`.vale.ini`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.vale.ini) configuration) on the modified `*.md` files. Tags: `documentation`, `style`.
 
@@ -146,7 +146,7 @@ One way to generate the initial list is to run the `todo` auto generation,
 with `exclude limit` set to a high number.
 
 ```shell
-bundle exec rubocop --auto-gen-config --auto-gen-only-exclude --exclude-limit=10000
+bundle exec rubocop --auto-gen-config --auto-gen-only-exclude --exclude-limit=100000
 ```
 
 You can then move the list from the freshly generated `.rubocop_todo.yml` for the Cop being actively
@@ -154,6 +154,16 @@ resolved and place it in the `.rubocop_manual_todo.yml`. In this scenario, do no
 changes to the `.rubocop_todo.yml` as an `exclude limit` that is higher than 15 will make 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`.
+
+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`.
+
 ## Database migrations
 
 See the dedicated [Database Migrations Style Guide](../migration_style_guide.md).