Update "navigate" to "go"

data/deprecations/15-0-deprecate-monitor-tracing.yml

@@ -3,7 +3,7 @@
   removal_milestone: "15.0"  # The milestone when this feature is planned to be removed
   breaking_change: true  # If this deprecation is a breaking change, set this value to true
   body: |  # Do not modify this line, instead modify the lines below.
-    Tracing in GitLab is an integration with Jaeger, an open-source end-to-end distributed tracing system. GitLab users can navigate to their Jaeger instance to gain insight into the performance of a deployed application, tracking each function or microservice that handles a given request. Tracing in GitLab is deprecated in GitLab 14.7, and scheduled for removal in 15.0. To track work on a possible replacement, see the issue for [Opstrace integration with GitLab](https://gitlab.com/groups/gitlab-org/-/epics/6976).
+    Tracing in GitLab is an integration with Jaeger, an open-source end-to-end distributed tracing system. GitLab users can go to their Jaeger instance to gain insight into the performance of a deployed application, tracking each function or microservice that handles a given request. Tracing in GitLab is deprecated in GitLab 14.7, and scheduled for removal in 15.0. To track work on a possible replacement, see the issue for [Opstrace integration with GitLab](https://gitlab.com/groups/gitlab-org/-/epics/6976).
 # The following items are not published on the docs page, but may be used in the future.
   stage: Monitor  # (optional - may be required in the future) String value of the stage that the feature was created in. e.g., Growth
   tiers: [Free]  # (optional - may be required in the future) An array of tiers that the feature is available in currently.  e.g., [Free, Silver, Gold, Core, Premium, Ultimate]

doc/administration/admin_area.md

@@ -448,7 +448,7 @@ The **System Info** page provides the following statistics:
 | Disk Usage     | Disk space in use, and total disk space available |
 | System started | When the system hosting GitLab was started. In GitLab 15.1 and earlier, this was an uptime statistic. |
 
-These statistics are updated only when you navigate to the **System Info** page, or you refresh the page in your browser.
+These statistics are updated only when you go to the **System Info** page, or you refresh the page in your browser.
 
 ### Background Jobs
 

doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md

@@ -54,7 +54,7 @@ Before following any of those steps, make sure you have `root` access to the
 **secondary** to promote it, since there isn't provided an automated way to
 promote a Geo replica and perform a failover.
 
-On the **secondary** site, navigate to the **Admin Area > Geo** dashboard to
+On the **secondary** site, go to the **Admin Area > Geo** dashboard to
 review its status. Replicated objects (shown in green) should be close to 100%,
 and there should be no failures (shown in red). If a large proportion of
 objects aren't yet replicated (shown in gray), consider giving the site more

doc/administration/geo/replication/configuration.md

@@ -219,7 +219,7 @@ In the following steps, replace `<ssh_host_key_path>` with the one you're using:
    gitlab-ctl reconfigure
    ```
 
-1. Navigate to the Primary Node GitLab Instance:
+1. Go to the primary node GitLab instance:
    1. On the left sidebar, at the bottom, select **Admin Area**.
    1. On the left sidebar, select **Geo > Sites**.
    1. Select **Add site**.

doc/administration/geo/replication/troubleshooting.md

@@ -1494,7 +1494,7 @@ If these kinds of risks do not apply, for example in a test environment, or if y
    ```
 
 1. The secondary site should appear healthy. If it does not, run `gitlab-rake gitlab:geo:check` on the secondary site, or try restarting Rails if you haven't done so since re-adding the secondary site.
-1. To resync missing or out-of-date data, navigate to **Admin > Geo > Sites**.
+1. To resync missing or out-of-date data, go to **Admin > Geo > Sites**.
 1. Under the secondary site select **Replication Details**.
 1. Select **Reverify all** for every data type.
 

doc/administration/geo/setup/two_single_node_sites.md

@@ -555,7 +555,7 @@ You must manually replicate the secret file across all of your secondary sites,
    gitlab-ctl reconfigure
    ```
 
-1. Navigate to the primary node GitLab instance:
+1. Go to the primary node GitLab instance:
    1. On the left sidebar, at the bottom, select **Admin Area**.
    1. Select **Geo > Sites**.
    1. Select **Add site**.

doc/administration/integration/terminal.md

@@ -40,7 +40,7 @@ In brief:
 
 - GitLab relies on the user to provide their own Kubernetes credentials, and to
   appropriately label the pods they create when deploying.
-- When a user navigates to the terminal page for an environment, they are served
+- When a user goes to the terminal page for an environment, they are served
   a JavaScript application that opens a WebSocket connection back to GitLab.
 - The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse),
   rather than the Rails application server.

doc/administration/settings/account_and_limit_settings.md

@@ -134,11 +134,11 @@ there are no restrictions.
 These settings can be found in:
 
 - Each project's settings:
-  1. From the Project's homepage, navigate to **Settings > General**.
+  1. From the Project's homepage, go to **Settings > General**.
   1. Fill in the **Repository size limit (MiB)** field in the **Naming, topics, avatar** section.
   1. Select **Save changes**.
 - Each group's settings:
-  1. From the Group's homepage, navigate to **Settings > General**.
+  1. From the Group's homepage, go to **Settings > General**.
   1. Fill in the **Repository size limit (MiB)** field in the **Naming, visibility** section.
   1. Select **Save changes**.
 - GitLab global settings:

doc/administration/settings/sign_in_restrictions.md

@@ -189,7 +189,7 @@ To access this text box:
 1. Expand the **Sign-in restrictions** section.
 ```
 
-Your users see the **Custom sign-in text** when they navigate to the sign-in screen for your
+Your users see the **Custom sign-in text** when they go to the sign-in screen for your
 GitLab instance.
 
 ## Troubleshooting

doc/api/graphql/sample_issue_boards.md

@@ -45,7 +45,7 @@ instance of the [GraphiQL explorer](https://gitlab.com/-/graphql-explorer):
 
 ![GraphiQL explorer search for boards](img/sample_issue_boards_v13_2.png)
 
-If you want to view one of these boards, take one of the numeric identifiers shown in the output. From the screenshot, the first identifier is `105011`. Navigate to the following URL, which includes the identifier:
+If you want to view one of these boards, take one of the numeric identifiers shown in the output. From the screenshot, the first identifier is `105011`. Go to the following URL, which includes the identifier:
 
 ```markdown
 https://gitlab.com/gitlab-org/gitlab-docs/-/boards/105011

doc/architecture/blueprints/cells/feature_flags.md

@@ -63,7 +63,7 @@ Let's use an example. Let's say we want to change feature flag `lorem_ipsum_dola
 
 > `/chatops run feature set lorem_ipsum_dolar ayufan`
 
-The command only change the flag for that actor on our Primary Cell. All other cells will be ignored. We may be able to expand Chatops to be able to accept an added flag such that we could directly set the actor on a particular Cell. Doing so will require the Engineer to know which Cell an actor resides. The reason for these limitations is to account for the fact that users and projects may be spread across a multitude of Cells. Cells are also being designed such that we can migrate data from one Cell to another. Feature Flag data is stored as a setting on a Cell and thus the metadata associated with what flags are set are not part of the knowledge associated with an actor. This introduces risk that if we target an actor, and later that actor is moved, the flag would no longer be set properly. This will lead to differing behavior for a given actor, but normally these types of changes happen to internal customers to GitLab reducing risk that users will notice a behavioral change as they navigate between Cells. This implementation is also simplistic, removing the need to query _some service_ which hosts the Cells and actor resides, and needing to develop a specialized rollout procedure when the resulting target may be more than a single Cell. This is discussed a bit more in the next section.
+The command only change the flag for that actor on our Primary Cell. All other cells will be ignored. We may be able to expand Chatops to be able to accept an added flag such that we could directly set the actor on a particular Cell. Doing so will require the Engineer to know which Cell an actor resides. The reason for these limitations is to account for the fact that users and projects may be spread across a multitude of Cells. Cells are also being designed such that we can migrate data from one Cell to another. Feature Flag data is stored as a setting on a Cell and thus the metadata associated with what flags are set are not part of the knowledge associated with an actor. This introduces risk that if we target an actor, and later that actor is moved, the flag would no longer be set properly. This will lead to differing behavior for a given actor, but normally these types of changes happen to internal customers to GitLab reducing risk that users will notice a behavioral change as they switch between Cells. This implementation is also simplistic, removing the need to query _some service_ which hosts the Cells and actor resides, and needing to develop a specialized rollout procedure when the resulting target may be more than a single Cell. This is discussed a bit more in the next section.
 
 ##### Engagement on Environments
 

doc/architecture/blueprints/cells/impacted_features/your-work.md

@@ -57,4 +57,4 @@ Considering that [we expect most users to work in a single Organization](../../o
 
 ## 4.2. Cons
 
-- Users working across multiple Organizations will have to navigate to each Organization to access all of their work items.
+- Users working across multiple Organizations will have to go to each Organization to access all of their work items.

doc/architecture/blueprints/cells/rejected/proposal-stateless-router-with-buffering-requests.md

@@ -341,7 +341,7 @@ projects/namespaces but their MR/Todo/Issue counts at the top of the page will
 not be correctly populated in the first iteration. The user will be aware of
 this limitation.
 
-#### Navigates to `/my-company/my-project` while logged in
+#### Goes to `/my-company/my-project` while logged in
 
 1. User is in Europe so DNS resolves to the router in Europe
 1. They request `/my-company/my-project` without the router cache, so the router chooses randomly `Cell EU1`
@@ -362,7 +362,7 @@ sequenceDiagram
     cell_eu0->>user: <h1>My Project... X-Gitlab-Cell-Cache={path_prefix:/my-company/}
 ```
 
-#### Navigates to `/my-company/my-project` while not logged in
+#### Goes to `/my-company/my-project` while not logged in
 
 1. User is in Europe so DNS resolves to the router in Europe
 1. The router does not have `/my-company/*` cached yet so it chooses randomly `Cell EU1`
@@ -394,7 +394,7 @@ sequenceDiagram
     cell_eu0->>user: <h1>My Project... X-Gitlab-Cell-Cache={path_prefix:/my-company/}
 ```
 
-#### Navigates to `/my-company/my-other-project` after last step
+#### Goes to `/my-company/my-other-project` after last step
 
 1. User is in Europe so DNS resolves to the router in Europe
 1. The router cache now has `/my-company/* => Cell EU0`, so the router chooses `Cell EU0`
@@ -411,7 +411,7 @@ sequenceDiagram
     cell_eu0->>user: <h1>My Project... X-Gitlab-Cell-Cache={path_prefix:/my-company/}
 ```
 
-#### Navigates to `/gitlab-org/gitlab` after last step
+#### Goes to `/gitlab-org/gitlab` after last step
 
 1. User is in Europe so DNS resolves to the router in Europe
 1. The router has no cached value for this URL so randomly chooses `Cell EU0`
@@ -436,7 +436,7 @@ counter will not include their typical todos. We may choose to highlight this in
 the UI somewhere. A future iteration may be able to fetch that for them from
 their default organization.
 
-#### Navigates to `/`
+#### Goes to `/`
 
 1. User is in Europe so DNS resolves to the router in Europe
 1. Router does not have a cache for `/` route (specifically rails never tells it to cache this route)
@@ -464,12 +464,12 @@ sequenceDiagram
     cell_eu0->>user: <h1>My Company Dashboard... X-Gitlab-Cell-Cache={path_prefix:/organizations/my-organization/}
 ```
 
-#### Navigates to `/dashboard`
+#### Goes to `/dashboard`
 
 As above, they will end up on `/organizations/my-organization/-/dashboard` as
 the rails application will already redirect `/` to the dashboard page.
 
-### Navigates to `/not-my-company/not-my-project` while logged in (but they don't have access since this project/group is private)
+### Goes to `/not-my-company/not-my-project` while logged in (but they don't have access since this project/group is private)
 
 1. User is in Europe so DNS resolves to the router in Europe
 1. The router knows that `/not-my-company` lives in `Cell US1` so sends the request to this
@@ -502,11 +502,11 @@ the Rails application knows to interpret this organization to mean that they are
 allowed to use legacy global functionality like `/dashboard` to see data across
 namespaces located on `Cell US0`. The rails backend also knows that the default cell to render any ambiguous
 routes like `/dashboard` is `Cell US0`. Lastly the user will be allowed to
-navigate to organizations on another cell like `/my-organization` but when they do the
+go to organizations on another cell like `/my-organization` but when they do the
 user will see a message indicating that some data may be missing (for example, the
 MRs/Issues/Todos) counts.
 
-#### Navigates to `/gitlab-org/gitlab` while not logged in
+#### Goes to `/gitlab-org/gitlab` while not logged in
 
 1. User is in the US so DNS resolves to the US router
 1. The router knows that `/gitlab-org` lives in `Cell US0` so sends the request
@@ -523,7 +523,7 @@ sequenceDiagram
     cell_us0->>user: <h1>GitLab.org... X-Gitlab-Cell-Cache={path_prefix:/gitlab-org/}
 ```
 
-#### Navigates to `/`
+#### Goes to `/`
 
 1. User is in US so DNS resolves to the router in US
 1. Router does not have a cache for `/` route (specifically rails never tells it to cache this route)
@@ -555,7 +555,7 @@ sequenceDiagram
     cell_us0->>user: <h1>Dashboard...
 ```
 
-#### Navigates to `/my-company/my-other-project` while logged in (but they don't have access since this project is private)
+#### Goes to `/my-company/my-other-project` while logged in (but they don't have access since this project is private)
 
 They get a 404.
 

doc/architecture/blueprints/cells/rejected/proposal-stateless-router-with-routes-learning.md

@@ -360,7 +360,7 @@ projects/namespaces but their MR/Todo/Issue counts at the top of the page will
 not be correctly populated in the first iteration. The user will be aware of
 this limitation.
 
-#### Navigates to `/my-company/my-project` while logged in
+#### Goes to `/my-company/my-project` while logged in
 
 1. User is in Europe so DNS resolves to the router in Europe
 1. They request `/my-company/my-project` without the router cache, so the router chooses randomly `Cell EU1`
@@ -381,7 +381,7 @@ sequenceDiagram
     cell_eu0->>user: <h1>My Project...
 ```
 
-#### Navigates to `/my-company/my-project` while not logged in
+#### Goes to `/my-company/my-project` while not logged in
 
 1. User is in Europe so DNS resolves to the router in Europe
 1. The router does not have `/my-company/*` cached yet so it chooses randomly `Cell EU1`
@@ -417,7 +417,7 @@ sequenceDiagram
     cell_eu0->>user: <h1>My Project...
 ```
 
-#### Navigates to `/my-company/my-other-project` after last step
+#### Goes to `/my-company/my-other-project` after last step
 
 1. User is in Europe so DNS resolves to the router in Europe
 1. The router cache now has `/my-company/* => Cell EU0`, so the router chooses `Cell EU0`
@@ -434,7 +434,7 @@ sequenceDiagram
     cell_eu0->>user: <h1>My Project...
 ```
 
-#### Navigates to `/gitlab-org/gitlab` after last step
+#### Goes to `/gitlab-org/gitlab` after last step
 
 1. User is in Europe so DNS resolves to the router in Europe
 1. The router has no cached value for this URL so randomly chooses `Cell EU0`
@@ -459,7 +459,7 @@ counter will not include their typical todos. We may choose to highlight this in
 the UI somewhere. A future iteration may be able to fetch that for them from
 their default organization.
 
-#### Navigates to `/`
+#### Goes to `/`
 
 1. User is in Europe so DNS resolves to the router in Europe
 1. Router does not have a cache for `/` route (specifically rails never tells it to cache this route)
@@ -487,12 +487,12 @@ sequenceDiagram
     cell_eu0->>user: <h1>My Company Dashboard... X-Gitlab-Cell-Cache={path_prefix:/organizations/my-organization/}
 ```
 
-#### Navigates to `/dashboard`
+#### Goes to `/dashboard`
 
 As above, they will end up on `/organizations/my-organization/-/dashboard` as
 the rails application will already redirect `/` to the dashboard page.
 
-### Navigates to `/not-my-company/not-my-project` while logged in (but they don't have access since this project/group is private)
+### Goes to `/not-my-company/not-my-project` while logged in (but they don't have access since this project/group is private)
 
 1. User is in Europe so DNS resolves to the router in Europe
 1. The router knows that `/not-my-company` lives in `Cell US1` so sends the request to this
@@ -525,11 +525,11 @@ the Rails application knows to interpret this organization to mean that they are
 allowed to use legacy global functionality like `/dashboard` to see data across
 namespaces located on `Cell US0`. The rails backend also knows that the default cell to render any ambiguous
 routes like `/dashboard` is `Cell US0`. Lastly the user will be allowed to
-navigate to organizations on another cell like `/my-organization` but when they do the
+go to organizations on another cell like `/my-organization` but when they do the
 user will see a message indicating that some data may be missing (eg. the
 MRs/Issues/Todos) counts.
 
-#### Navigates to `/gitlab-org/gitlab` while not logged in
+#### Goes to `/gitlab-org/gitlab` while not logged in
 
 1. User is in the US so DNS resolves to the US router
 1. The router knows that `/gitlab-org` lives in `Cell US0` so sends the request
@@ -546,7 +546,7 @@ sequenceDiagram
     cell_us0->>user: <h1>GitLab.org...
 ```
 
-#### Navigates to `/`
+#### Goes to `/`
 
 1. User is in US so DNS resolves to the router in US
 1. Router does not have a cache for `/` route (specifically rails never tells it to cache this route)
@@ -578,7 +578,7 @@ sequenceDiagram
     cell_us0->>user: <h1>Dashboard...
 ```
 
-#### Navigates to `/my-company/my-other-project` while logged in (but they don't have access since this project is private)
+#### Goes to `/my-company/my-other-project` while logged in (but they don't have access since this project is private)
 
 They get a 404.
 

doc/architecture/blueprints/cells/routing-service.md

@@ -13,7 +13,7 @@ into architecture take a look at [Infrastructure Architecture](infrastructure/in
 
 ## Goals
 
-The routing layer is meant to offer a consistent user experience where all Cells are presented under a single domain (for example, `gitlab.com`), instead of having to navigate to separate domains.
+The routing layer is meant to offer a consistent user experience where all Cells are presented under a single domain (for example, `gitlab.com`), instead of having to go to separate domains.
 
 The user will be able to use `https://gitlab.com` to access Cell-enabled GitLab.
 Depending on the URL access, it will be transparently proxied to the correct Cell that can serve this particular information.
@@ -575,7 +575,7 @@ Cell EU0:
 }
 ```
 
-#### Navigates to `/my-company/my-project` while logged in into Cell EU0
+#### Goes to `/my-company/my-project` while logged in into Cell EU0
 
 1. Because user switched the Organization to `my-company`, its session cookie is prefixed with `eu0_`.
 1. User sends request `/my-company/my-project`, and because the cookie is prefixed with `eu0_` it is directed to Cell EU0.
@@ -592,7 +592,7 @@ sequenceDiagram
     cell_eu0->>user: <h1>My Project...
 ```
 
-#### Navigates to `/my-company/my-project` while not logged in
+#### Goes to `/my-company/my-project` while not logged in
 
 1. User visits `/my-company/my-project`, and because it does not have session cookie, the request is forwarded to `Cell US0`.
 1. User signs in.
@@ -621,7 +621,7 @@ sequenceDiagram
     cell_eu0->>user: <h1>My Project...
 ```
 
-#### Navigates to `/gitlab-org/gitlab` after last step
+#### Goes to `/gitlab-org/gitlab` after last step
 
 User visits `/my-company/my-project`, and because it does not have a session cookie, the request is forwarded to `Cell US0`.
 
@@ -667,7 +667,7 @@ Cell US0 and EU0:
 }
 ```
 
-#### Navigates to `/my-company/my-project` while logged in into Cell EU0
+#### Goes to `/my-company/my-project` while logged in into Cell EU0
 
 1. The `/my-company/my-project/` is visited.
 1. Router decodes sharding key `top_level_group=my-company`.
@@ -693,7 +693,7 @@ sequenceDiagram
     cell_eu0->>user: <h1>My Project...
 ```
 
-#### Navigates to `/my-company/my-project` while not logged in
+### Goes to `/my-company/my-project` while not logged in
 
 1. The `/my-company/my-project/` is visited.
 1. Router decodes sharding key `top_level_group=my-company`.
@@ -734,7 +734,7 @@ sequenceDiagram
     cell_eu0->>user: <h1>My Project...
 ```
 
-#### Navigates to `/gitlab-org/gitlab` after last step
+#### Goes to `/gitlab-org/gitlab` after last step
 
 1. Because the `/gitlab-org` is not found in cache, it will be classified and then directed to correct Cell.
 

doc/ci/components/examples.md

@@ -20,7 +20,7 @@ Depending on a component's functionality, [testing the component](index.md#test-
 
 The following "hello world" example for the Rust programming language uses the `cargo` tool chain for simplicity:
 
-1. Navigate into the CI/CD component root directory.
+1. Go to the CI/CD component root directory.
 1. Initialize a new Rust project by using the `cargo init` command.
 
    ```shell

doc/ci/examples/end_to_end_testing_webdriverio/index.md

@@ -64,7 +64,7 @@ We will be using [Jasmine](https://jasmine.github.io/) here:
 
 ```javascript
 describe('A visitor without account', function(){
-    it('should be able to navigate to the homepage from the 404 page', function(){
+    it('should be able to go to the homepage from the 404 page', function(){
         browser.url('/page-that-does-not-exist');
 
         expect(browser.getUrl()).toMatch('page-that-does-not-exist');

doc/ci/examples/laravel_with_gitlab_and_envoy/index.md

@@ -284,7 +284,7 @@ The `--depth 1` option is a great solution which saves systems time and disk spa
 
 #### Installing dependencies with Composer
 
-As you may know, this task just navigates to the new release directory and runs Composer to install the application dependencies:
+This task goes to the new release directory and runs Composer to install the application dependencies:
 
 ```php
 ...
@@ -440,7 +440,7 @@ Now that we have our `Dockerfile` let's build and push it to our [GitLab contain
 
 > The registry is the place to store and tag images for later use. Developers may want to maintain their own registry for private, company images, or for throw-away images used only in testing. Using GitLab container registry means you don't need to set up and administer yet another service or use a public registry.
 
-On your GitLab project repository navigate to the **Registry** tab.
+In your GitLab project repository, go to the **Registry** tab.
 
 ![container registry page empty image](img/container_registry_page_empty_image.png)
 
@@ -636,7 +636,7 @@ After our code passed through the pipeline successfully, we can deploy to our pr
 
 ![pipelines page deploy button](img/pipelines_page_deploy_button.png)
 
-After the deploy pipeline passed successfully, navigate to **Pipelines > Environments**.
+After the deploy pipeline passes successfully, go to **Pipelines > Environments**.
 
 ![environments page](img/environments_page.png)
 
@@ -655,7 +655,7 @@ The `.env` file consists of our Laravel environment variables.
 
 ![production server app directory](img/production_server_app_directory.png)
 
-If you navigate to the `current` directory, you should see the application's content.
+If you go to the `current` directory, you should see the application's content.
 As you see, the `.env` is pointing to the `/var/www/app/.env` file and also `storage` is pointing to the `/var/www/app/storage/` directory.
 
 ![production server current directory](img/production_server_current_directory.png)

doc/ci/examples/semantic-release.md

@@ -16,7 +16,7 @@ You can also view or fork the complete [example source](https://gitlab.com/gitla
 
 ## Initialize the module
 
-1. Open a terminal and navigate to the project's repository.
+1. Open a terminal and go to the project's repository.
 1. Run `npm init`. Name the module according to [the package registry's naming conventions](../../user/packages/npm_registry/index.md#naming-convention). For example, if the project's path is `gitlab-examples/semantic-release-npm`, name the module `@gitlab-examples/semantic-release-npm`.
 
 1. Install the following npm packages:

doc/ci/jobs/job_control.md

@@ -726,7 +726,7 @@ test:
     - bundle exec rspec_booster --job $CI_NODE_INDEX/$CI_NODE_TOTAL
 ```
 
-You can then navigate to the **Jobs** tab of a new pipeline build and see your RSpec
+You can then go to the **Jobs** tab of a new pipeline build and see your RSpec
 job split into three separate jobs.
 
 WARNING: