Add latest changes from gitlab-org/gitlab@master

11 files changed, 20 insertions, 20 deletions

diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index 9844dca6bb9..6a88e7b71e2 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -762,7 +762,7 @@ a hash with the input for the mutation. This will return a struct with
 a mutation query, and prepared variables.
 
 This struct can then be passed to the `post_graphql_mutation` helper,
-that will post the request with the correct params, like a GraphQL
+that will post the request with the correct parameters, like a GraphQL
 client would do.
 
 To access the response of a mutation, the `graphql_mutation_response`
diff --git a/doc/development/api_styleguide.md b/doc/development/api_styleguide.md
index 8537c63a8b7..7c0146017b1 100644
--- a/doc/development/api_styleguide.md
+++ b/doc/development/api_styleguide.md
@@ -28,7 +28,7 @@ for a good example):
   - The GitLab version when the endpoint was added. If it is behind a feature flag, mention that instead: _This feature is gated by the :feature\_flag\_symbol feature flag._
   - If the endpoint is deprecated, and if so, when will it be removed
 
-- `params` for the method params. This acts as description,
+- `params` for the method parameters. This acts as description,
   [validation, and coercion of the parameters]
 
 A good example is as follows:
@@ -49,22 +49,22 @@ get do
 end
 ```
 
-## Declared params
+## Declared parameters
 
 > Grape allows you to access only the parameters that have been declared by your
-`params` block. It filters out the params that have been passed, but are not
+`params` block. It filters out the parameters that have been passed, but are not
 allowed.
 
 – <https://github.com/ruby-grape/grape#declared>
 
-### Exclude params from parent namespaces
+### Exclude parameters from parent namespaces
 
 > By default `declared(params)`includes parameters that were defined in all
 parent namespaces.
 
 – <https://github.com/ruby-grape/grape#include-parent-namespaces>
 
-In most cases you will want to exclude params from the parent namespaces:
+In most cases you will want to exclude parameters from the parent namespaces:
 
 ```ruby
 declared(params, include_parent_namespaces: false)
@@ -72,7 +72,7 @@ declared(params, include_parent_namespaces: false)
 
 ### When to use `declared(params)`
 
-You should always use `declared(params)` when you pass the params hash as
+You should always use `declared(params)` when you pass the parameters hash as
 arguments to a method call.
 
 For instance:
diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index 061e910a6d0..d065660be74 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -150,7 +150,7 @@ Component statuses are linked to configuration documentation for each component.
 | [Node Exporter](#node-exporter) | Prometheus endpoint with system metrics | [✅][node-exporter-omnibus] | [N/A][node-exporter-charts] | [N/A][node-exporter-charts] | [✅](https://about.gitlab.com/handbook/engineering/monitoring/) | ❌ | ❌ | CE & EE |
 | [Mattermost](#mattermost) | Open-source Slack alternative | [⚙][mattermost-omnibus] | [⤓][mattermost-charts] | [⤓][mattermost-charts] | [⤓](../user/project/integrations/mattermost.md) | ❌ | ❌ | CE & EE |
 | [MinIO](#minio) | Object storage service | [⤓][minio-omnibus] | [✅][minio-charts] | [✅][minio-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#storage-architecture) | ❌ | [⚙][minio-gdk] | CE & EE |
-| [Runner](#gitlab-runner) | Executes GitLab CI jobs | [⤓][runner-omnibus] | [✅][runner-charts] | [⚙][runner-charts] | [✅](../user/gitlab_com/index.md#shared-runners) | [⚙][runner-source] | [⚙][runner-gdk] | CE & EE |
+| [Runner](#gitlab-runner) | Executes GitLab CI/CD jobs | [⤓][runner-omnibus] | [✅][runner-charts] | [⚙][runner-charts] | [✅](../user/gitlab_com/index.md#shared-runners) | [⚙][runner-source] | [⚙][runner-gdk] | CE & EE |
 | [Database Migrations](#database-migrations) | Database migrations | [✅][database-migrations-omnibus] | [✅][database-migrations-charts] | [✅][database-migrations-charts] | ✅ | [⚙][database-migrations-source] | ✅ | CE & EE |
 | [Certificate Management](#certificate-management) | TLS Settings, Let's Encrypt | [✅][certificate-management-omnibus] | [✅][certificate-management-charts] | [⚙][certificate-management-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#secrets-management) | [⚙][certificate-management-source] | [⚙][certificate-management-gdk] | CE & EE |
 | [GitLab Geo Node](#gitlab-geo) | Geographically distributed GitLab nodes | [⚙][geo-omnibus] | [❌][geo-charts] | [❌][geo-charts] | ✅ | ❌ | [⚙][geo-gdk] | EE Only |
@@ -263,7 +263,7 @@ You can use it either for personal or business websites, such as portfolios, doc
 
 GitLab Runner runs tests and sends the results to GitLab.
 
-GitLab CI is the open-source continuous integration service included with GitLab that coordinates the testing. The old name of this project was GitLab CI Multi Runner but please use "GitLab Runner" (without CI) from now on.
+GitLab CI/CD is the open-source continuous integration service included with GitLab that coordinates the testing. The old name of this project was `GitLab CI Multi Runner` but please use `GitLab Runner` (without CI) from now on.
 
 #### GitLab Shell
 
diff --git a/doc/development/auto_devops.md b/doc/development/auto_devops.md
index fb2992623df..656fb2ed1ad 100644
--- a/doc/development/auto_devops.md
+++ b/doc/development/auto_devops.md
@@ -5,7 +5,7 @@ This document provides a development guide for contributors to
 
 ## Development
 
-Auto DevOps builds on top of GitLab CI to create an automatic pipeline
+Auto DevOps builds on top of GitLab CI/CD to create an automatic pipeline
 based on your project contents. When Auto DevOps is enabled for a
 project, the user does not need to explicitly include any pipeline configuration
 through a [`.gitlab-ci.yml` file](../ci/yaml/README.md).
diff --git a/doc/development/dangerbot.md b/doc/development/dangerbot.md
index b6362f04311..2e4451949aa 100644
--- a/doc/development/dangerbot.md
+++ b/doc/development/dangerbot.md
@@ -1,6 +1,6 @@
 # Danger bot
 
-The GitLab CI pipeline includes a `danger-review` job that uses [Danger](https://github.com/danger/danger)
+The GitLab CI/CD pipeline includes a `danger-review` job that uses [Danger](https://github.com/danger/danger)
 to perform a variety of automated checks on the code under test.
 
 Danger is a gem that runs in the CI environment, like any other analysis tool.
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index 2a5779d2fe3..b386d0e78ff 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -506,17 +506,17 @@ end
 Note that due to namespace differences, we need to use the full qualifier for some
 constants.
 
-#### EE params
+#### EE parameters
 
 We can define `params` and utilize `use` in another `params` definition to
-include params defined in EE. However, we need to define the "interface" first
+include parameters defined in EE. However, we need to define the "interface" first
 in CE in order for EE to override it. We don't have to do this in other places
 due to `prepend_if_ee`, but Grape is complex internally and we couldn't easily
 do that, so we'll follow regular object-oriented practices that we define the
 interface first here.
 
-For example, suppose we have a few more optional params for EE. We can move the
-params out of the `Grape::API` class to a helper module, so we can inject it
+For example, suppose we have a few more optional parameters for EE. We can move the
+paramters out of the `Grape::API` class to a helper module, so we can inject it
 before it would be used in the class.
 
 ```ruby
diff --git a/doc/development/fe_guide/style/scss.md b/doc/development/fe_guide/style/scss.md
index 6d378db417b..83dd7990951 100644
--- a/doc/development/fe_guide/style/scss.md
+++ b/doc/development/fe_guide/style/scss.md
@@ -245,7 +245,7 @@ ruleset in `.scss-lint.yml`, which is located in the home directory of the
 project.
 
 To check if any warnings will be produced by your changes, you can run `rake
-scss_lint` in the GitLab directory. SCSS Lint will also run in GitLab CI to
+scss_lint` in the GitLab directory. SCSS Lint will also run in GitLab CI/CD to
 catch any warnings.
 
 If the Rake task is throwing warnings you don't understand, SCSS Lint's
diff --git a/doc/development/feature_flags/development.md b/doc/development/feature_flags/development.md
index b3fc9c291c6..d1b1bd00e1b 100644
--- a/doc/development/feature_flags/development.md
+++ b/doc/development/feature_flags/development.md
@@ -81,7 +81,7 @@ Feature groups must be defined statically in `lib/feature.rb` (in the
 dynamic (querying the DB etc.).
 
 Once defined in `lib/feature.rb`, you will be able to activate a
-feature for a given feature group via the [`feature_group` param of the features API](../../api/features.md#set-or-create-a-feature)
+feature for a given feature group via the [`feature_group` parameter of the features API](../../api/features.md#set-or-create-a-feature)
 
 ### Frontend
 
diff --git a/doc/development/integrations/secure.md b/doc/development/integrations/secure.md
index e5392af1c2e..3b5071f767c 100644
--- a/doc/development/integrations/secure.md
+++ b/doc/development/integrations/secure.md
@@ -170,7 +170,7 @@ it is recommended to expose configuration as environment variables, not files.
 
 ### Output file
 
-Like any artifact uploaded to the GitLab CI,
+Like any artifact uploaded to the GitLab CI/CD,
 the Secure report generated by the scanner must be written in the project directory,
 given by the `CI_PROJECT_DIR` environment variable.
 
diff --git a/doc/development/internal_api.md b/doc/development/internal_api.md
index 60aec3a720a..e8fca7535b0 100644
--- a/doc/development/internal_api.md
+++ b/doc/development/internal_api.md
@@ -15,7 +15,7 @@ default this is in the root of the rails app named
 `.gitlab_shell_secret`
 
 To authenticate using that token, clients read the contents of that
-file, and include the token Base64 encoded in a `secret_token` param
+file, and include the token Base64 encoded in a `secret_token` parameter
 or in the `Gitlab-Shared-Secret` header.
 
 NOTE: **Note:**
diff --git a/doc/development/merge_request_performance_guidelines.md b/doc/development/merge_request_performance_guidelines.md
index d395bf13982..a285d30d7a5 100644
--- a/doc/development/merge_request_performance_guidelines.md
+++ b/doc/development/merge_request_performance_guidelines.md
@@ -377,7 +377,7 @@ Examples:
    in service degradation as the system will try to process all schedules
    assigned the the project.
 
-1. GitLab CI includes: We started with the limit of maximum of 50 nested includes.
+1. GitLab CI/CD includes: We started with the limit of maximum of 50 nested includes.
    We understood that performance of the feature was acceptable at that level.
    We received a request from the community that the limit is too small.
    We had a time to understand the customer requirement, and implement an additional