Merge branch 'docs-utilize-rule' into 'master'

Update utilize rule to warning level suggestion

See merge request gitlab-org/gitlab!47873

doc/.vale/gitlab/SubstitutionSuggestions.yml

@@ -12,7 +12,6 @@ level: suggestion
 ignorecase: true
 swap:
   since: because
-  utilize: use
   once that: after that
   once the: after the
   once you: after you

doc/.vale/gitlab/SubstitutionWarning.yml

@@ -18,3 +18,4 @@ swap:
   filesystem: file system
   info: information
   repo: repository
+  utilize: use

doc/administration/geo/index.md

@@ -49,7 +49,7 @@ Geo provides:
 
 - Read-only **secondary** nodes: Maintain one **primary** GitLab node while still enabling read-only **secondary** nodes for each of your distributed teams.
 - Authentication system hooks: **Secondary** nodes receives all authentication data (like user accounts and logins) from the **primary** instance.
-- An intuitive UI: **Secondary** nodes utilize the same web interface your team has grown accustomed to. In addition, there are visual notifications that block write operations and make it clear that a user is on a **secondary** node.
+- An intuitive UI: **Secondary** nodes use the same web interface your team has grown accustomed to. In addition, there are visual notifications that block write operations and make it clear that a user is on a **secondary** node.
 
 ## How it works
 

doc/administration/load_balancer.md

@@ -114,7 +114,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
 
 ## Readiness check
 
-It is strongly recommend that multi-node deployments configure load balancers to utilize the [readiness check](../user/admin_area/monitoring/health_check.md#readiness) to ensure a node is ready to accept traffic, before routing traffic to it. This is especially important when utilizing Puma, as there is a brief period during a restart where Puma will not accept requests.
+It is strongly recommend that multi-node deployments configure load balancers to use the [readiness check](../user/admin_area/monitoring/health_check.md#readiness) to ensure a node is ready to accept traffic, before routing traffic to it. This is especially important when utilizing Puma, as there is a brief period during a restart where Puma will not accept requests.
 
 <!-- ## Troubleshooting
 

doc/administration/monitoring/prometheus/index.md

@@ -26,7 +26,7 @@ access to high quality time-series monitoring of GitLab services.
 Prometheus works by periodically connecting to data sources and collecting their
 performance metrics through the [various exporters](#bundled-software-metrics). To view
 and work with the monitoring data, you can either
-[connect directly to Prometheus](#viewing-performance-metrics) or utilize a
+[connect directly to Prometheus](#viewing-performance-metrics) or use a
 dashboard tool like [Grafana](https://grafana.com).
 
 ## Configuring Prometheus

doc/administration/operations/puma.md

@@ -33,7 +33,7 @@ will _not_ carry over automatically, due to differences between the two applicat
 deployments, see [Configuring Puma Settings](https://docs.gitlab.com/omnibus/settings/puma.html#configuring-puma-settings).
 For Helm based deployments, see the [Webservice Chart documentation](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
 
-Additionally we strongly recommend that multi-node deployments [configure their load balancers to utilize the readiness check](../load_balancer.md#readiness-check) due to a difference between Unicorn and Puma in how they handle connections during a restart of the service.
+Additionally we strongly recommend that multi-node deployments [configure their load balancers to use the readiness check](../load_balancer.md#readiness-check) due to a difference between Unicorn and Puma in how they handle connections during a restart of the service.
 
 ## Performance caveat when using Puma with Rugged
 

doc/administration/packages/dependency_proxy.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7934) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.11.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/273655) to [GitLab Core](https://about.gitlab.com/pricing/) in GitLab 13.6.
 
-GitLab can be utilized as a dependency proxy for a variety of common package managers.
+GitLab can be used as a dependency proxy for a variety of common package managers.
 
 This is the administration documentation. If you want to learn how to use the
 dependency proxies, see the [user guide](../../user/packages/dependency_proxy/index.md).

doc/administration/packages/index.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # GitLab Package Registry administration
 
-GitLab Packages allows organizations to utilize GitLab as a private repository
+GitLab Packages allows organizations to use GitLab as a private repository
 for a variety of common package managers. Users are able to build and publish
 packages, which can be easily consumed as a dependency in downstream projects.
 

doc/administration/troubleshooting/elasticsearch.md

@@ -171,7 +171,7 @@ The first step is to confirm GitLab is using Elasticsearch for the search functi
 To do this:
 
 1. Confirm the integration is enabled in **Admin Area > Settings > General**.
-1. Confirm searches utilize Elasticsearch by accessing the rails console
+1. Confirm searches use Elasticsearch by accessing the rails console
    (`sudo gitlab-rails console`) and running the following commands:
 
    ```rails

doc/api/container_registry.md

@@ -280,7 +280,7 @@ This action doesn't delete blobs. To delete them and recycle disk space,
 Delete registry repository tags in bulk based on given criteria.
 
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-For an overview, see [Utilize the Container Registry API to delete all tags except *](https://youtu.be/Hi19bKe_xsg).
+For an overview, see [Use the Container Registry API to delete all tags except *](https://youtu.be/Hi19bKe_xsg).
 
 ```plaintext
 DELETE /projects/:id/registry/repositories/:repository_id/tags

doc/development/approval_rules.md

@@ -147,7 +147,7 @@ Whenever an approval is given/revoked, a record is created/deleted.
 
 ## Controllers and Services
 
-The following controllers and services below are being utilized for the approval
+The following controllers and services below are being used for the approval
 rules feature to work.
 
 ### `API::ProjectApprovalSettings`

doc/development/architecture.md

@@ -945,7 +945,7 @@ processes: `puma master` (1 process), `puma cluster worker`
 
 ### Repository access
 
-Repositories get accessed via HTTP or SSH. HTTP cloning/push/pull utilizes the GitLab API and SSH cloning is handled by GitLab Shell (previously explained).
+Repositories get accessed via HTTP or SSH. HTTP cloning/push/pull uses the GitLab API and SSH cloning is handled by GitLab Shell (previously explained).
 
 ## Troubleshooting
 

doc/development/chaos_endpoints.md

@@ -85,7 +85,7 @@ GET /-/chaos/cpu_spin?duration_s=50&async=true
 
 | Attribute    | Type    | Required | Description                                                           |
 | ------------ | ------- | -------- | --------------------------------------------------------------------- |
-| `duration_s` | integer | no       | Duration, in seconds, that the core will be utilized. Defaults to 30s |
+| `duration_s` | integer | no       | Duration, in seconds, that the core will be used. Defaults to 30s |
 | `async`      | boolean | no       | Set to true to consume CPU in a Sidekiq background worker process     |
 
 ```shell
@@ -110,7 +110,7 @@ GET /-/chaos/db_spin?duration_s=50&async=true
 | Attribute    | Type    | Required | Description                                                                 |
 | ------------ | ------- | -------- | --------------------------------------------------------------------------- |
 | `interval_s` | float   | no       | Interval, in seconds, for every DB request. Defaults to 1s                  |
-| `duration_s` | integer | no       | Duration, in seconds, that the core will be utilized. Defaults to 30s       |
+| `duration_s` | integer | no       | Duration, in seconds, that the core will be used. Defaults to 30s       |
 | `async`      | boolean | no       | Set to true to perform the operation in a Sidekiq background worker process |
 
 ```shell

doc/development/ee_features.md

@@ -573,7 +573,7 @@ constants.
 
 #### EE parameters
 
-We can define `params` and utilize `use` in another `params` definition to
+We can define `params` and use `use` in another `params` definition to
 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

doc/development/fe_guide/vue.md

@@ -120,7 +120,7 @@ return new Vue({
 Use Vue's [provide/inject](https://vuejs.org/v2/api/#provide-inject) mechanism
 to make feature flags available to any descendant components in a Vue
 application. The `glFeatures` object is already provided in `commons/vue.js`, so
-only the mixin is required to utilize the flags:
+only the mixin is required to use the flags:
 
 ```javascript
 // An arbitrary descendant component

doc/development/product_analytics/snowplow.md

@@ -52,7 +52,7 @@ Tracking can be enabled at:
 - The instance level, which enables tracking on both the frontend and backend layers.
 - User level, though user tracking can be disabled on a per-user basis. GitLab tracking respects the [Do Not Track](https://www.eff.org/issues/do-not-track) standard, so any user who has enabled the Do Not Track option in their browser is not tracked at a user level.
 
-We utilize Snowplow for the majority of our tracking strategy and it is enabled on GitLab.com. On a self-managed instance, Snowplow can be enabled by navigating to:
+We use Snowplow for the majority of our tracking strategy and it is enabled on GitLab.com. On a self-managed instance, Snowplow can be enabled by navigating to:
 
 - **Admin Area > Settings > General** in the UI.
 - `admin/application_settings/integrations` in your browser.
@@ -112,7 +112,7 @@ The current method provides several attributes that are sent on each click event
 
 ## Implementing Snowplow JS (Frontend) tracking
 
-GitLab provides `Tracking`, an interface that wraps the [Snowplow JavaScript Tracker](https://github.com/snowplow/snowplow/wiki/javascript-tracker) for tracking custom events. There are a few ways to utilize tracking, but each generally requires at minimum, a `category` and an `action`. Additional data can be provided that adheres to our [Structured event taxonomy](#structured-event-taxonomy).
+GitLab provides `Tracking`, an interface that wraps the [Snowplow JavaScript Tracker](https://github.com/snowplow/snowplow/wiki/javascript-tracker) for tracking custom events. There are a few ways to use tracking, but each generally requires at minimum, a `category` and an `action`. Additional data can be provided that adheres to our [Structured event taxonomy](#structured-event-taxonomy).
 
 | field      | type   | default value              | description                                                                                                                                                                                                    |
 |:-----------|:-------|:---------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
@@ -294,7 +294,7 @@ Custom event tracking and instrumentation can be added by directly calling the `
 | `action`   | string | 'generic'     | The action being taken, which can be anything from a controller action like `create` to something like an Active Record callback.                                                                                                                                      |
 | `data`     | object | {}            | Additional data such as `label`, `property`, `value`, and `context` as described in [Structured event taxonomy](#structured-event-taxonomy). These are set as empty strings if you don't provide them. |
 
-Tracking can be viewed as either tracking user behavior, or can be utilized for instrumentation to monitor and visualize performance over time in an area or aspect of code.
+Tracking can be viewed as either tracking user behavior, or can be used for instrumentation to monitor and visualize performance over time in an area or aspect of code.
 
 For example:
 

doc/development/secure_coding_guidelines.md

@@ -269,7 +269,7 @@ When user submitted data is included in responses to end users, which is just ab
 
 ### Mitigation
 
-In most situations, a two-step solution can be utilized: input validation and output encoding in the appropriate context.
+In most situations, a two-step solution can be used: input validation and output encoding in the appropriate context.
 
 #### Input validation
 

doc/development/sidekiq_style_guide.md

@@ -821,7 +821,7 @@ This approach requires multiple releases.
 ##### Parameter hash
 
 This approach will not require multiple releases if an existing worker already
-utilizes a parameter hash.
+uses a parameter hash.
 
 1. Use a parameter hash in the worker to allow future flexibility.
 

doc/integration/elasticsearch.md

@@ -58,7 +58,7 @@ A few notes on CPU and storage:
   see boosts in both query and indexing performance.
 
 Keep in mind, these are **minimum requirements** for Elasticsearch.
-Heavily-utilized Elasticsearch clusters will likely require considerably more
+Heavily-used Elasticsearch clusters will likely require considerably more
 resources.
 
 ## Installing Elasticsearch

doc/operations/metrics/dashboards/yaml.md

@@ -87,8 +87,8 @@ is no longer used.
 | `id` | string | no | Used for associating dashboard metrics with database records. Must be unique across dashboard configuration files. Required for [alerting](../alerts.md) (support not yet enabled, see [relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/27980)). |
 | `unit` | string | yes | Defines the unit of the query's return data. |
 | `label` | string | no, but highly encouraged | Defines the legend-label for the query. Should be unique within the panel's metrics. Can contain time series labels as interpolated variables. |
-| `query` | string/number | yes if `query_range` is not defined | Defines the Prometheus query to be used to populate the chart/panel. If defined, the `query` endpoint of the [Prometheus API](https://prometheus.io/docs/prometheus/latest/querying/api/) will be utilized. |
-| `query_range` | string/number | yes if `query` is not defined | Defines the Prometheus query to be used to populate the chart/panel. If defined, the `query_range` endpoint of the [Prometheus API](https://prometheus.io/docs/prometheus/latest/querying/api/) will be utilized. |
+| `query` | string/number | yes if `query_range` is not defined | Defines the Prometheus query to be used to populate the chart/panel. If defined, the `query` endpoint of the [Prometheus API](https://prometheus.io/docs/prometheus/latest/querying/api/) will be used. |
+| `query_range` | string/number | yes if `query` is not defined | Defines the Prometheus query to be used to populate the chart/panel. If defined, the `query_range` endpoint of the [Prometheus API](https://prometheus.io/docs/prometheus/latest/querying/api/) will be used. |
 | `step` | number | no, value is calculated if not defined | Defines query resolution step width in float number of seconds. Metrics on the same panel should use the same `step` value. |
 
 ## Dynamic labels

doc/raketasks/backup_restore.md

@@ -335,7 +335,7 @@ sudo -u git -H GITLAB_ASSUME_YES=1 bundle exec rake gitlab:backup:restore RAILS_
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37158) in GitLab 13.3.
 
-Repositories can be backed up concurrently to help fully utilize CPU time. The
+Repositories can be backed up concurrently to help fully use CPU time. The
 following variables are available to modify the default behavior of the Rake
 task:
 

doc/topics/gitlab_flow.md

@@ -250,7 +250,7 @@ Atlassian has a more thorough explanation of the tradeoffs between merging and r
 A good way to prevent creating many merge commits is to not frequently merge `master` into the feature branch.
 There are three reasons to merge in `master`: utilizing new code, resolving merge conflicts, and updating long-running branches.
 
-If you need to utilize some code that was introduced in `master` after you created the feature branch, you can often solve this by just cherry-picking a commit.
+If you need to use some code that was introduced in `master` after you created the feature branch, you can often solve this by just cherry-picking a commit.
 
 If your feature branch has a merge conflict, creating a merge commit is a standard way of solving this.
 

doc/user/project/code_owners.md

@@ -27,7 +27,7 @@ who is responsible for each file or path.
 Code Owners allows for a version controlled, single source of
 truth file outlining the exact GitLab users or groups that
 own certain files or paths in a repository. Code Owners can be
-utilized in the merge request approval process which can streamline
+used in the merge request approval process which can streamline
 the process of finding the right reviewers and approvers for a given
 merge request.