Add latest changes from gitlab-org/gitlab@master

6 files changed, 45 insertions, 20 deletions

diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index 64a59796ebc..61e42ecfe83 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -399,7 +399,7 @@ merge request with new or changed docs is submitted, are:
     - The `CHANGELOG.md` does not contain duplicate versions.
     - No files in `doc/` are executable.
     - No new `README.md` was added.
-  - [`markdownlint`](#markdownlint).
+  - [markdownlint](#markdownlint).
   - Nanoc tests, which you can [run locally](#previewing-the-changes-live) before
     pushing to GitLab by executing the command `bundle exec nanoc check internal_links`
     (or `internal_anchors`) on your local [`gitlab-docs`](https://gitlab.com/gitlab-org/gitlab-docs) directory:
@@ -420,7 +420,7 @@ help you catch common issues before raising merge requests for review of documen
 The following are some suggested linters you can install locally and sample configuration:
 
 - [`proselint`](#proselint)
-- [`markdownlint`](#markdownlint), which is the same as the test run in [`docs-lint`](#testing)
+- [markdownlint](#markdownlint), which is the same as the test run in [`docs-lint`](#testing)
 
 NOTE: **Note:**
 This list does not limit what other linters you can add to your local documentation writing toolchain.
@@ -464,18 +464,18 @@ noise. The following sample `proselint` configuration disables these checks:
 A file with `proselint` configuration must be placed in a
 [valid location](https://github.com/amperser/proselint#checks). For example, `~/.config/proselint/config`.
 
-#### `markdownlint`
+#### markdownlint
 
-[`markdownlint`](https://github.com/DavidAnson/markdownlint) checks that Markdown
+[markdownlint](https://github.com/DavidAnson/markdownlint) checks that Markdown
 syntax follows [certain rules](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#rules),
 and is used by the [`docs-lint` test](#testing) with a [configuration file](#markdownlint-configuration).
 Our [Documentation Style Guide](styleguide.md#markdown) and [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/)
 elaborate on which choices must be made when selecting Markdown syntax for GitLab
 documentation. This tool helps catch deviations from those guidelines.
 
-`markdownlint` can be used [on the command line](https://github.com/igorshubovych/markdownlint-cli#markdownlint-cli--),
+markdownlint can be used [on the command line](https://github.com/igorshubovych/markdownlint-cli#markdownlint-cli--),
 either on a single Markdown file or on all Markdown files in a project. For example, to run
-`markdownlint` on all documentation in the [`gitlab` project](https://gitlab.com/gitlab-org/gitlab),
+markdownlint on all documentation in the [`gitlab` project](https://gitlab.com/gitlab-org/gitlab),
 run the following commands from within your `gitlab` project root directory, which will
 automatically detect the [`.markdownlint.json`](#markdownlint-configuration) config
 file in the root of the project, and test all files in `/doc` and its subdirectories:
@@ -490,7 +490,7 @@ If you wish to use a different config file, use the `-c` flag:
 markdownlint -c <config-file-name> 'doc/**/*.md'
 ```
 
-`markdownlint` can also be run from within text editors using [plugins/extensions](https://github.com/DavidAnson/markdownlint#related),
+markdownlint can also be run from within text editors using [plugins/extensions](https://github.com/DavidAnson/markdownlint#related),
 such as:
 
 - [Sublime Text](https://packagecontrol.io/packages/SublimeLinter-contrib-markdownlint)
@@ -502,9 +502,9 @@ is in use in the four repos that are the sources for <https://docs.gitlab.com>.
 plugin/extension has different requirements regarding the configuration file, which
 is explained in each editor's docs.
 
-##### `markdownlint` configuration
+##### markdownlint configuration
 
-Each formatting issue that `markdownlint` checks has an associated
+Each formatting issue that markdownlint checks has an associated
 [rule](https://github.com/DavidAnson/markdownlint/blob/master/doc/Rules.md#rules).
 These rules are configured in the `.markdownlint.json` files located in the root of
 four repos that are the sources for <https://docs.gitlab.com>:
@@ -518,7 +518,7 @@ By default all rules are enabled, so the configuration file is used to disable u
 rules, and also to configure optional parameters for enabled rules as needed. You can
 also check [the issue](https://gitlab.com/gitlab-org/gitlab-foss/issues/64352) that
 tracked the changes required to implement these rules, and details which rules were
-on or off when `markdownlint` was enabled on the docs.
+on or off when markdownlint was enabled on the docs.
 
 ## Danger Bot
 
diff --git a/doc/development/documentation/styleguide.md b/doc/development/documentation/styleguide.md
index b604c94e016..385569fc8fa 100644
--- a/doc/development/documentation/styleguide.md
+++ b/doc/development/documentation/styleguide.md
@@ -111,11 +111,38 @@ Hard-coded HTML is valid, although it's discouraged to be used while we have `/h
 
 GitLab ensures that the Markdown used across all documentation is consistent, as
 well as easy to review and maintain, by [testing documentation changes](index.md#testing) with
-[`markdownlint`](index.md#markdownlint). This lint test fails when any document has an issue
+[markdownlint](index.md#markdownlint). This lint test fails when any document has an issue
 with Markdown formatting that may cause the page to render incorrectly within GitLab.
 It will also fail when a document is using non-standard Markdown (which may render
 correctly, but is not the current standard for GitLab documentation).
 
+#### Markdown rule `MD044/proper-names` (capitalization)
+
+A rule that could cause confusion is `MD044/proper-names`, as it might not be immediately
+clear what caused markdownlint to fail, or how to correct the failure. This rule
+checks a list of known words, listed in the `.markdownlint.json` file in each project,
+to verify that proper capitalization and backticks are used. Words in backticks will
+be ignored by markdownlint.
+
+In general, product names should follow the exact capitalization of the official names
+of the products, protocols, etc.
+
+Some examples that will fail if incorrect capitalization is used:
+
+- MinIO (needs capital `IO`)
+- NGINX (needs all capitals)
+- runit (needs lowercase `r`)
+
+Additionally, commands, parameters, values, filenames, etc. must be included in backticks.
+For example:
+
+- "Change the `needs` keyword in your `.gitlab.yml`..."
+  - `needs` is a parameter, and `.gitlab.yml` is a file, so both need backticks. Additionally,
+    `.gitlab.yml` will fail markdownlint without backticks as it does not have capital G or L.
+- "Run `git clone` to clone a Git repository..."
+  - `git clone` is a command, so it must be lowercase, while Git is the product, so
+    it must have a capital G.
+
 ## Structure
 
 ### Organize by topic, not by type
diff --git a/doc/development/experiment_guide/index.md b/doc/development/experiment_guide/index.md
index c7a80a07c61..98086fc63ea 100644
--- a/doc/development/experiment_guide/index.md
+++ b/doc/development/experiment_guide/index.md
@@ -24,7 +24,7 @@ The author then adds a comment to this piece of code and adds a link to the issu
 
 ## How to create an A/B test
 
-- [ ] Add the experiment to the `Gitlab::Experimentation::EXPERIMENTS` hash in [`experimentation.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib%2Fgitlab%2Fexperimentation.rb):
+- Add the experiment to the `Gitlab::Experimentation::EXPERIMENTS` hash in [`experimentation.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib%2Fgitlab%2Fexperimentation.rb):
 
   ```ruby
   EXPERIMENTS = {
@@ -40,7 +40,7 @@ The author then adds a comment to this piece of code and adds a link to the issu
   }.freeze
   ```
 
-- [ ] Use the experiment in a controller:
+- Use the experiment in a controller:
 
   ```ruby
   class RegistrationController < Applicationcontroller
@@ -55,8 +55,8 @@ The author then adds a comment to this piece of code and adds a link to the issu
   end
   ```
 
-- [ ] Track necessary events. See the [event tracking guide](../event_tracking/index.md) for details.
-- [ ] After the merge request is merged, use [`chatops`](../../ci/chatops/README.md) to enable the feature flag and start the experiment. For visibility, please run the command in the `#s_growth` channel:
+- Track necessary events. See the [event tracking guide](../event_tracking/index.md) for details.
+- After the merge request is merged, use [`chatops`](../../ci/chatops/README.md) to enable the feature flag and start the experiment. For visibility, please run the command in the `#s_growth` channel:
 
   ```
   /chatops run feature set --project=gitlab-org/gitlab experimental_sign_up_flow true
diff --git a/doc/development/fe_guide/style/scss.md b/doc/development/fe_guide/style/scss.md
index a8755e634be..c6424e39ac2 100644
--- a/doc/development/fe_guide/style/scss.md
+++ b/doc/development/fe_guide/style/scss.md
@@ -11,7 +11,7 @@ easy to maintain, and performant for the end-user.
 
 ### Utility Classes
 
-As part of the effort for [cleaning up our CSS and moving our components into GitLab-UI](https://gitlab.com/groups/gitlab-org/-/epics/950)
+As part of the effort for [cleaning up our CSS and moving our components into gitlab-ui](https://gitlab.com/groups/gitlab-org/-/epics/950)
 led by the [GitLab UI WG](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/20623) we prefer the use of utility classes over adding new CSS. However, complex CSS can be addressed by adding component classes.
 
 #### Where are utility classes defined?
diff --git a/doc/development/fe_guide/tooling.md b/doc/development/fe_guide/tooling.md
index ec5e094cfa6..066c2575e2d 100644
--- a/doc/development/fe_guide/tooling.md
+++ b/doc/development/fe_guide/tooling.md
@@ -2,7 +2,7 @@
 
 ## ESLint
 
-We use ESLint to encapsulate and enforce frontend code standards. Our configuration may be found in the [gitlab-eslint-config](https://gitlab.com/gitlab-org/gitlab-eslint-config) project.
+We use ESLint to encapsulate and enforce frontend code standards. Our configuration may be found in the [`gitlab-eslint-config`](https://gitlab.com/gitlab-org/gitlab-eslint-config) project.
 
 ### Disabling ESLint in new files
 
diff --git a/doc/development/internal_api.md b/doc/development/internal_api.md
index 18d88c37147..dbb721b6018 100644
--- a/doc/development/internal_api.md
+++ b/doc/development/internal_api.md
@@ -287,8 +287,6 @@ Example response:
 }
 ```
 
-## Notify Post Receive [UNUSED] ?
-
 ## PostReceive
 
 Called from Gitaly after a receiving a push. This triggers the
@@ -300,7 +298,7 @@ the user.
 |:----------|:-------|:---------|:------------|
 | `identifier` | string | yes | `user-[id]` or `key-[id]` Identifying the user performing the push |
 | `gl_repository` | string | yes | identifier of the repository being pushed to |
-| `push_options` | [string] | no | array of push options |
+| `push_options` | string array | no | array of push options |
 | `changes` | string | no | refs to be updated in the push in the format `oldrev newrev refname\n`. |
 
 ```