Merge branch 'docs-aqualls-spellspell' into 'master'

Even more exciting spelling corrections!

See merge request gitlab-org/gitlab!52940

doc/.vale/gitlab/spelling-exceptions.txt

@@ -12,6 +12,7 @@ Ansible
 Anthos
 approvers
 architected
+architecting
 Arel
 Artifactory
 Asana
@@ -357,6 +358,7 @@ onboarding
 OpenID
 OpenShift
 Opsgenie
+Overcommit
 Packagist
 parallelization
 parallelizations
@@ -408,6 +410,7 @@ pseudocode
 pseudonymized
 pseudonymizer
 Puma
+pytest
 Python
 Qualys
 queryable
@@ -438,6 +441,8 @@ referer
 referers
 reflog
 reflogs
+refspec
+refspecs
 reindex
 reindexed
 reindexes
@@ -503,6 +508,7 @@ Silverlight
 Sisense
 Sitespeed
 Slack
+Slackbot
 Slony
 smartcard
 smartcards
@@ -545,11 +551,15 @@ subquery
 subquerying
 substring
 substrings
+subtask
+subtasks
 subtree
 subtrees
 sudo
 supercookie
 supercookies
+supertype
+supertypes
 swappiness
 swimlane
 swimlanes

doc/administration/troubleshooting/kubernetes_cheat_sheet.md

@@ -70,7 +70,7 @@ and they will assist you with any issues you are having.
   kubectl logs <pod-name> --previous
   ```
 
-  No logs are kept in the containers/pods themselves. Everything is written to stdout.
+  No logs are kept in the containers/pods themselves. Everything is written to `stdout`.
   This is the principle of Kubernetes, read [Twelve-factor app](https://12factor.net/)
   for details.
 

doc/ci/README.md

@@ -71,7 +71,7 @@ available through the UI. You can use them by creating a new file,
 choosing a template that suits your application, and adjusting it
 to your needs:
 
-![Use a `.gitlab-ci.yml` template](img/add_file_template_11_10.png)
+![Use a YAML template](img/add_file_template_11_10.png)
 
 While building your `.gitlab-ci.yml`, you can use the [CI/CD configuration visualization](pipeline_editor/index.md#visualize-ci-configuration) to facilitate your writing experience.
 

doc/ci/ci_cd_for_external_repos/bitbucket_integration.md

@@ -14,8 +14,9 @@ GitLab CI/CD can be used with Bitbucket Cloud by:
 
 To use GitLab CI/CD with a Bitbucket Cloud repository:
 
-1. In GitLab create a **CI/CD for external repository**, select **Repo by URL** and
-   create the project.
+1. <!-- vale gitlab.Spelling = NO --> In GitLab create a **CI/CD for external repository**, select
+   **Repo by URL** and create the project.
+   <!-- vale gitlab.Spelling = YES -->
 
    ![Create project](img/external_repository.png)
 

doc/ci/ci_cd_for_external_repos/index.md

@@ -25,11 +25,15 @@ snippets disabled. These features
 
 To connect to an external repository:
 
+<!-- vale gitlab.Spelling = NO -->
+
 1. From your GitLab dashboard, click **New project**.
 1. Switch to the **CI/CD for external repository** tab.
 1. Choose **GitHub** or **Repo by URL**.
 1. The next steps are similar to the [import flow](../../user/project/import/index.md).
 
+<!-- vale gitlab.Spelling = YES -->
+
 ![CI/CD for external repository project creation](img/ci_cd_for_external_repo.png)
 
 ## Pipelines for external pull requests

doc/ci/docker/using_docker_build.md

@@ -126,7 +126,7 @@ not without its own challenges:
   instance of Docker engine so they don't conflict with each other. But this
   also means that jobs can be slower because there's no caching of layers.
 - By default, Docker 17.09 and higher uses `--storage-driver overlay2` which is
-  the recommended storage driver. See [Using the overlayfs driver](#use-the-overlayfs-driver)
+  the recommended storage driver. See [Using the OverlayFS driver](#use-the-overlayfs-driver)
   for details.
 - Since the `docker:19.03.12-dind` container and the runner container don't share their
   root file system, the job's working directory can be used as a mount point for

doc/ci/environments/environments_dashboard.md

@@ -36,7 +36,7 @@ environments are not displayed.
 
 To add a project to the dashboard:
 
-1. Click the **Add projects** button in the homescreen of the dashboard.
+1. Click the **Add projects** button in the home screen of the dashboard.
 1. Search and add one or more projects using the **Search your projects** field.
 1. Click the **Add projects** button.
 

doc/ci/lint.md

@@ -4,8 +4,10 @@ group: unassigned
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 <!-- markdownlint-disable MD044 -->
+<!-- vale gitlab.Spelling = NO -->
 # Validate .gitlab-ci.yml syntax with the CI Lint tool
 <!-- markdownlint-enable MD044 -->
+<!-- vale gitlab.Spelling = YES -->
 
 If you want to test the validity of your GitLab CI/CD configuration before committing
 the changes, you can use the CI Lint tool. This tool checks for syntax and logical

doc/ci/parent_child_pipelines.md

@@ -156,7 +156,11 @@ build a matrix of targets and architectures.
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
 For an overview, see [Create child pipelines using dynamically generated configurations](https://youtu.be/nMdfus2JWHM).
 
-We also have an [example project using Dynamic Child Pipelines with Jsonnet](https://gitlab.com/gitlab-org/project-templates/jsonnet) which shows how to use a data templating language to generate your `.gitlab-ci.yml` at runtime. You could use a similar process for other templating languages like [Dhall](https://dhall-lang.org/) or [`ytt`](https://get-ytt.io/).
+<!-- vale gitlab.Spelling = NO -->
+We also have an example project using
+[Dynamic Child Pipelines with Jsonnet](https://gitlab.com/gitlab-org/project-templates/jsonnet)
+which shows how to use a data templating language to generate your `.gitlab-ci.yml` at runtime. You could use a similar process for other templating languages like [Dhall](https://dhall-lang.org/) or [`ytt`](https://get-ytt.io/).
+<!-- vale gitlab.Spelling = NO -->
 
 The artifact path is parsed by GitLab, not the runner, so the path must match the
 syntax for the OS running GitLab. If GitLab is running on Linux but using a Windows

doc/ci/pipelines/settings.md

@@ -131,6 +131,8 @@ averaged.
 
 ![Build status coverage](img/pipelines_test_coverage_build.png)
 
+<!-- vale gitlab.Spelling = NO -->
+
 | Coverage Tool                                  | Sample regular expression |
 |------------------------------------------------|---------------------------|
 | Simplecov (Ruby)                               | `\(\d+.\d+\%\) covered` |
@@ -145,6 +147,8 @@ averaged.
 | JaCoCo (Java/Kotlin)                           | `Total.*?([0-9]{1,3})%` |
 | `go test -cover` (Go)                          | `coverage: \d+.\d+% of statements` |
 
+<!-- vale gitlab.Spelling = YES -->
+
 ### Code Coverage history
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209121) the ability to download a `.csv` in GitLab 12.10.
@@ -154,7 +158,7 @@ To see the evolution of your project code coverage over time,
 you can view a graph or download a CSV file with this data. From your project:
 
 1. Go to **{chart}** **Project Analytics > Repository** to see the historic data for each job listed in the dropdown above the graph.
-1. If you want a CSV file of that data, click **Download raw data (.csv)**
+1. If you want a CSV file of that data, click **Download raw data (`.csv`)**
 
 ![Code coverage graph of a project over time](img/code_coverage_graph_v13_1.png)
 

doc/development/adding_service_component.md

@@ -65,7 +65,7 @@ Notify the [Distribution team](https://about.gitlab.com/handbook/engineering/dev
 
 New services to be bundled with GitLab need to be available in the following environments.
 
-**Dev environment**
+**Development environment**
 
 The first step of bundling a new service is to provide it in the development environment to engage in collaboration and feedback.
 

doc/development/api_graphql_styleguide.md

@@ -1683,7 +1683,7 @@ full stack:
 - An argument or scalar's [`prepare`](#validating-arguments) applies correctly.
 - Logic in a resolver or mutation's [`#ready?` method](#correct-use-of-resolverready) applies correctly.
 - An [argument's `default_value`](https://graphql-ruby.org/fields/arguments.html) applies correctly.
-- Objects resolve performantly and there are no N+1 issues.
+- Objects resolve successfully, and there are no N+1 issues.
 
 When adding a query, you can use the `a working graphql query` shared example to test if the query
 renders valid results.

doc/development/architecture.md

@@ -934,7 +934,7 @@ ps aux | grep '^git'
 ```
 
 GitLab has several components to operate. It requires a persistent database
-(PostgreSQL) and Redis database, and uses Apache `httpd` or NGINX to proxypass
+(PostgreSQL) and Redis database, and uses Apache `httpd` or NGINX to `proxypass`
 Puma. All these components should run as different system users to GitLab
 (for example, `postgres`, `redis`, and `www-data`, instead of `git`).
 

doc/development/chaos_endpoints.md

@@ -6,8 +6,12 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Generating chaos in a test GitLab instance
 
+<!-- vale gitlab.Spelling = NO -->
+
 As [Werner Vogels](https://twitter.com/Werner), the CTO at Amazon Web Services, famously put it, **Everything fails, all the time**.
 
+<!-- vale gitlab.Spelling = NO -->
+
 As a developer, it's as important to consider the failure modes in which your software may operate as much as normal operation. Doing so can mean the difference between a minor hiccup leading to a scattering of `500` errors experienced by a tiny fraction of users, and a full site outage that affects all users for an extended period.
 
 To paraphrase [Tolstoy](https://en.wikipedia.org/wiki/Anna_Karenina_principle), _all happy servers are alike, but all failing servers are failing in their own way_. Luckily, there are ways we can attempt to simulate these failure modes, and the chaos endpoints are tools for assisting in this process.

doc/development/code_intelligence/index.md

@@ -45,7 +45,7 @@ sequenceDiagram
    GitLab Rails to authorize the upload.
 
 1. GitLab Rails validates whether the artifact can be uploaded and sends
-   `ProcessLsif: true` header if the lsif artifact can be processed.
+   `ProcessLsif: true` header if the LSIF artifact can be processed.
 
 1. Workhorse reads the LSIF document line by line and generates code intelligence
    data for each file in the project. The output is a zipped directory of JSON

doc/development/code_review.md

@@ -344,7 +344,7 @@ experience, refactors the existing code). Then:
     convey your intent.
   - For non-mandatory suggestions, decorate with (non-blocking) so the author knows they can
     optionally resolve within the merge request or follow-up at a later stage.
-  - There's a [Chrome/Firefox addon](https://gitlab.com/conventionalcomments/conventional-comments-button) which you can use to apply [Conventional Comment](https://conventionalcomments.org/) prefixes.
+  - There's a [Chrome/Firefox add-on](https://gitlab.com/conventionalcomments/conventional-comments-button) which you can use to apply [Conventional Comment](https://conventionalcomments.org/) prefixes.
 - After a round of line notes, it can be helpful to post a summary note such as
   "Looks good to me", or "Just a couple things to address."
 - Assign the merge request to the author if changes are required following your
@@ -569,7 +569,7 @@ A good example of collaboration on an MR touching multiple parts of the codebase
 
 ### Credits
 
-Largely based on the [thoughtbot code review guide](https://github.com/thoughtbot/guides/tree/master/code-review).
+Largely based on the [`thoughtbot` code review guide](https://github.com/thoughtbot/guides/tree/master/code-review).
 
 ---
 

doc/development/contributing/style_guides.md

@@ -56,12 +56,12 @@ 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) config) 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) config) on the modified `*.html.haml` files. Tags: `view`, `haml`, `style`.
+- 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`.
+- 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) config) 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) config) 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) config) 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`.
+- 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`.
 
 In addition to the default configuration, you can define a [local configuration](https://github.com/Arkweid/lefthook/blob/master/docs/full_guide.md#local-config).
 
@@ -142,7 +142,7 @@ This ensures that our list isn't mistakenly removed by another auto generation o
 the `.rubocop_todo.yml`. This also allows us greater visibility into the exceptions
 which are currently being resolved.
 
-One way to generate the initial list is to run the todo auto generation,
+One way to generate the initial list is to run the `todo` auto generation,
 with `exclude limit` set to a high number.
 
 ```shell
@@ -180,8 +180,12 @@ See the dedicated [Shell scripting standards and style guidelines](../shell_scri
 
 ## Markdown
 
+<!-- vale gitlab.Spelling = NO -->
+
 We're following [Ciro Santilli's Markdown Style Guide](https://cirosantilli.com/markdown-style-guide/).
 
+<!-- vale gitlab.Spelling = YES -->
+
 ## Documentation
 
 See the dedicated [Documentation Style Guide](../documentation/styleguide/index.md).

doc/development/database/database_reviewer_guidelines.md

@@ -50,17 +50,17 @@ European/US and APAC friendly hours. You can join the office hours call and brin
 that require a more in-depth discussion between the database reviewers and maintainers:
 
 - [Database Office Hours Agenda](https://docs.google.com/document/d/1wgfmVL30F8SdMg-9yY6Y8djPSxWNvKmhR5XmsvYX1EI/edit).
-- [Youtube playlist with past recordings](https://www.youtube.com/playlist?list=PL05JrBw4t0Kp-kqXeiF7fF7cFYaKtdqXM).
+- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [YouTube playlist with past recordings](https://www.youtube.com/playlist?list=PL05JrBw4t0Kp-kqXeiF7fF7cFYaKtdqXM).
 
 You should also join the [#database-labs](../understanding_explain_plans.md#database-lab)
-Slack channel and get familiar with how to use Joe, the slackbot that provides developers
+Slack channel and get familiar with how to use Joe, the Slackbot that provides developers
 with their own clone of the production database.
 
 Understanding and efficiently using `EXPLAIN` plans is at the core of the database review process.
 The following guides provide a quick introduction and links to follow on more advanced topics:
 
 - Guide on [understanding EXPLAIN plans](../understanding_explain_plans.md).
-- [Explaining the unexplainable series in depesz](https://www.depesz.com/tag/unexplainable/).
+- [Explaining the unexplainable series in `depesz`](https://www.depesz.com/tag/unexplainable/).
 
 Finally, you can find various guides in the [Database guides](index.md) page that cover more specific
 topics and use cases. The most frequently required during database reviewing are the following:

doc/development/database/table_partitioning.md

@@ -60,7 +60,7 @@ was the first table to be partitioned in the application database
 (scheduled for deployment with the GitLab 13.5 release). This
 table tracks audit entries of security events that happen in the
 application. In almost all cases, users want to see audit activity that
-occurs in a certain timeframe. As a result, date-range partitioning
+occurs in a certain time frame. As a result, date-range partitioning
 was a natural fit for how the data would be accessed.
 
 To look at this in more detail, imagine a simplified `audit_events` schema:

doc/development/database_debugging.md

@@ -69,16 +69,14 @@ bundle exec rails db -e development
 Use these instructions for exploring the GitLab database while developing with the GDK:
 
 1. Install or open [Visual Studio Code](https://code.visualstudio.com/download).
-1. Install the [PostgreSQL VSCode Extension](https://marketplace.visualstudio.com/items?itemName=ckolkman.vscode-postgres) by Chris Kolkman.
+1. Install the [PostgreSQL VSCode Extension](https://marketplace.visualstudio.com/items?itemName=ckolkman.vscode-postgres).
 1. In Visual Studio Code click on the PostgreSQL Explorer button in the left toolbar.
 1. In the top bar of the new window, click on the `+` to **Add Database Connection**, and follow the prompts to fill in the details:
    1. **Hostname**: the path to the PostgreSQL folder in your GDK directory (for example `/dev/gitlab-development-kit/postgresql`).
    1. **PostgreSQL user to authenticate as**: usually your local username, unless otherwise specified during PostgreSQL installation.
    1. **Password of the PostgreSQL user**: the password you set when installing PostgreSQL.
    1. **Port number to connect to**: `5432` (default).
-   1. <!-- vale gitlab.Spelling = NO -->
-      **Use an ssl connection?**
-      <!-- vale gitlab.Spelling = YES --> This depends on your installation. Options are:
+   1. **Use an SSL connection?** This depends on your installation. Options are:
       - **Use Secure Connection**
       - **Standard Connection** (default)
    1. **(Optional) The database to connect to**: `gitlabhq_development`.

doc/development/database_review.md

@@ -147,7 +147,7 @@ test its execution using `CREATE INDEX CONCURRENTLY` in the `#database-lab` Slac
 - Provide the link to the plan at: [explain.depesz.com](https://explain.depesz.com). Paste both the plan and the query used in the form.
 - When providing query plans, make sure it hits enough data:
   - You can use a GitLab production replica to test your queries on a large scale,
-  through the `#database-lab` Slack channel or through [chatops](understanding_explain_plans.md#chatops).
+  through the `#database-lab` Slack channel or through [ChatOps](understanding_explain_plans.md#chatops).
   - Usually, the `gitlab-org` namespace (`namespace_id = 9970`) and the
   `gitlab-org/gitlab-foss` (`project_id = 13083`) or the `gitlab-org/gitlab` (`project_id = 278964`)
    projects provide enough data to serve as a good example.
@@ -220,13 +220,13 @@ test its execution using `CREATE INDEX CONCURRENTLY` in the `#database-lab` Slac
   - Check for any obviously complex queries and queries the author specifically
     points out for review (if any)
   - If not present yet, ask the author to provide SQL queries and query plans
-    (for example, by using [chatops](understanding_explain_plans.md#chatops) or direct
+    (for example, by using [ChatOps](understanding_explain_plans.md#chatops) or direct
     database access)
   - For given queries, review parameters regarding data distribution
   - [Check query plans](understanding_explain_plans.md) and suggest improvements
     to queries (changing the query, schema or adding indexes and similar)
   - General guideline is for queries to come in below [100ms execution time](query_performance.md#timing-guidelines-for-queries)
-  - Avoid N+1 problems and minimalize the [query count](merge_request_performance_guidelines.md#query-counts).
+  - Avoid N+1 problems and minimize the [query count](merge_request_performance_guidelines.md#query-counts).
 
 ### Timing guidelines for migrations
 

doc/development/diffs.md

@@ -14,12 +14,20 @@ We rely on different sources to present diffs. These include:
 
 ## Deep Dive
 
+<!-- vale gitlab.Spelling = NO -->
+
 In January 2019, Oswaldo Ferreira hosted a Deep Dive (GitLab team members only:
 `https://gitlab.com/gitlab-org/create-stage/issues/1`) on GitLab Diffs and Commenting on Diffs
-functionality to share his domain specific knowledge with anyone who may work in this part of the
-codebase in the future. You can find the <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> [recording on YouTube](https://www.youtube.com/watch?v=K6G3gMcFyek),
-and the slides on [Google Slides](https://docs.google.com/presentation/d/1bGutFH2AT3bxOPZuLMGl1ANWHqFnrxwQwjiwAZkF-TU/edit)
-and in [PDF](https://gitlab.com/gitlab-org/create-stage/uploads/b5ad2f336e0afcfe0f99db0af0ccc71a/).
+functionality to share domain-specific knowledge with anyone who may work in this part of the
+codebase in the future:
+
+<!-- vale gitlab.Spelling = YES -->
+
+- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+  [Recording on YouTube](https://www.youtube.com/watch?v=K6G3gMcFyek)
+- Slides on [Google Slides](https://docs.google.com/presentation/d/1bGutFH2AT3bxOPZuLMGl1ANWHqFnrxwQwjiwAZkF-TU/edit)
+- [PDF slides](https://gitlab.com/gitlab-org/create-stage/uploads/b5ad2f336e0afcfe0f99db0af0ccc71a/)
+
 Everything covered in this deep dive was accurate as of GitLab 11.7, and while specific details may
 have changed since then, it should still serve as a good introduction.
 

doc/development/documentation/index.md

@@ -514,7 +514,7 @@ To run the tool on an existing screenshot generator, take the following steps:
 1. Set up the [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/gitlab_docs.md).
 1. Navigate to the subdirectory with your cloned GitLab repository, typically `gdk/gitlab`.
 1. Make sure that your GDK database is fully migrated: `bin/rake db:migrate RAILS_ENV=development`.
-1. Install pngquant, see the tool website for more information: [`pngquant`](https://pngquant.org/)
+1. Install `pngquant`, see the tool website for more information: [`pngquant`](https://pngquant.org/)
 1. Run `scripts/docs_screenshots.rb spec/docs_screenshots/<name_of_screenshot_generator>.rb <milestone-version>`.
 1. Identify the location of the screenshots, based on the `gitlab/doc` location defined by the `it` parameter in your script.
 1. Commit the newly created screenshots.

doc/development/documentation/restful_api_styleguide.md

@@ -165,7 +165,7 @@ curl --request POST \
 
 ### Post data using form-data
 
-Instead of using JSON or urlencode you can use multipart/form-data which
+Instead of using JSON or URL-encoding data, you can use `multipart/form-data` which
 properly handles data encoding:
 
 ```shell

doc/development/documentation/site_architecture/index.md

@@ -114,7 +114,7 @@ located in the [Dockerfiles directory](https://gitlab.com/gitlab-org/gitlab-docs
 If you need to rebuild the Docker images immediately (must have maintainer level permissions):
 
 WARNING:
-If you change the dockerfile configuration and rebuild the images, you can break the master
+If you change the Dockerfile configuration and rebuild the images, you can break the master
 pipeline in the main `gitlab` repository as well as in `gitlab-docs`. Create an image with
 a different name first and test it to ensure you do not break the pipelines.
 

doc/development/documentation/testing.md

@@ -246,7 +246,7 @@ when building the `image:docs-lint-markdown` Docker image containing these tools
 | Tool               | Version  | Command                                   | Additional information |
 |--------------------|----------|-------------------------------------------|------------------------|
 | `markdownlint-cli` | Latest   | `yarn global add markdownlint-cli`        | n/a                    |
-| `markdownlint-cli` | Specfic  | `yarn global add markdownlint-cli@0.23.2` | The `@` indicates a specific version, and this example updates the tool to version `0.23.2`. |
+| `markdownlint-cli` | Specific  | `yarn global add markdownlint-cli@0.23.2` | The `@` indicates a specific version, and this example updates the tool to version `0.23.2`. |
 | Vale               | Latest   | `brew update && brew upgrade vale`        | This command is for macOS only. |
 | Vale               | Specific | n/a                                       | Not possible using `brew`, but can be [directly downloaded](https://github.com/errata-ai/vale/releases). |