Merge branch 'eread/fix-misused-terms' into 'master'

Fixes many instances of misused terms

See merge request gitlab-org/gitlab!26354

doc/administration/geo/replication/datatypes.md

@@ -75,7 +75,7 @@ GitLab stores files and blobs such as Issue attachments or LFS objects into eith
 - The filesystem in a specific location.
 - An Object Storage solution. Object Storage solutions can be:
   - Cloud based like Amazon S3 Google Cloud Storage.
-  - Self hosted (like MinIO).
+  - Hosted by you (like MinIO).
   - A Storage Appliance that exposes an Object Storage-compatible API.
 
 When using the filesystem store instead of Object Storage, you need to use network mounted filesystems

doc/administration/instance_limits.md

@@ -72,10 +72,10 @@ If a new pipeline would cause the total number of jobs to exceed the limit, the
 will fail with a `job_activity_limit_exceeded` error.
 
 - On GitLab.com different [limits are defined per plan](../user/gitlab_com/index.md#gitlab-cicd) and they affect all projects under that plan.
-- On [GitLab Starter](https://about.gitlab.com/pricing/#self-managed) tier or higher self-hosted installations, this limit is defined for the `default` plan that affects all projects.
+- On [GitLab Starter](https://about.gitlab.com/pricing/#self-managed) tier or higher self-managed installations, this limit is defined for the `default` plan that affects all projects.
   This limit is disabled by default.
 
-To set this limit on a self-hosted installation, run the following in the
+To set this limit on a self-managed installation, run the following in the
 [GitLab Rails console](https://docs.gitlab.com/omnibus/maintenance/#starting-a-rails-console-session):
 
 ```ruby
@@ -113,9 +113,9 @@ text field exceeds this limit then the text will be truncated to this number of
 characters and the rest will not be indexed and hence will not be searchable.
 
 - On GitLab.com this is limited to 20000 characters
-- For self-hosted installations it is unlimited by default
+- For self-managed installations it is unlimited by default
 
-This limit can be configured for self hosted installations when [enabling
+This limit can be configured for self-managed installations when [enabling
 Elasticsearch](../integration/elasticsearch.md#enabling-elasticsearch).
 
 NOTE: **Note:** Set the limit to `0` to disable it.

doc/administration/libravatar.md

@@ -9,7 +9,7 @@ GitLab by default supports the [Gravatar](https://gravatar.com) avatar service.
 Libravatar is another service that delivers your avatar (profile picture) to
 other websites. The Libravatar API is
 [heavily based on gravatar](https://wiki.libravatar.org/api/), so you can
-easily switch to the Libravatar avatar service or even a self-hosted Libravatar
+easily switch to the Libravatar avatar service or even your own Libravatar
 server.
 
 ## Configuration
@@ -35,7 +35,7 @@ the configuration options as follows:
     ssl_url: "https://seccdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
 ```
 
-### Self-hosted Libravatar server
+### Your own Libravatar server
 
 If you are [running your own libravatar service](https://wiki.libravatar.org/running_your_own/),
 the URL will be different in the configuration, but you must provide the same

doc/ci/docker/using_docker_images.md

@@ -693,7 +693,7 @@ To configure credentials store, follow these steps:
        }
      ```
 
-   - Or, if you are running self-hosted Runners, add the above JSON to
+   - Or, if you are running self-managed Runners, add the above JSON to
      `${GITLAB_RUNNER_HOME}/.docker/config.json`. GitLab Runner will read this config file
      and will use the needed helper for this specific repository.
 
@@ -726,7 +726,7 @@ To configure access for `aws_account_id.dkr.ecr.region.amazonaws.com`, follow th
      }
      ```
 
-   - Or, if you are running self-hosted Runners,
+   - Or, if you are running self-managed Runners,
      add the above JSON to `${GITLAB_RUNNER_HOME}/.docker/config.json`.
      GitLab Runner will read this config file and will use the needed helper for this
      specific repository.

doc/development/README.md

@@ -44,7 +44,7 @@ Complementary reads:
 - [Guidelines for implementing Enterprise Edition features](ee_features.md)
 - [Danger bot](dangerbot.md)
 - [Generate a changelog entry with `bin/changelog`](changelog.md)
-- [Requesting access to Chatops on GitLab.com](chatops_on_gitlabcom.md#requesting-access) (for GitLabbers)
+- [Requesting access to Chatops on GitLab.com](chatops_on_gitlabcom.md#requesting-access) (for GitLab team members)
 
 ## UX and Frontend guides
 

doc/development/deleting_migrations.md

 # Delete existing migrations
 
 When removing existing migrations from the GitLab project, you have to take into account
-the possibility of the migration already been included in past releases or in the current release, and thus already executed on GitLab.com and/or in self-hosted instances.
+the possibility of the migration already been included in past releases or in the current release, and thus already executed on GitLab.com and/or in self-managed instances.
 
 Because of it, it's not possible to delete existing migrations, as that could lead to:
 

doc/development/feature_flags/controls.md

@@ -147,7 +147,7 @@ is always on or off to the users.
 ## Cleaning up
 
 Once the change is deemed stable, submit a new merge request to remove the
-feature flag. This ensures the change is available to all users and self-hosted
+feature flag. This ensures the change is available to all users and self-managed
 instances. Make sure to add the ~"feature flag" label to this merge request so
 release managers are aware the changes are hidden behind a feature flag. If the
 merge request has to be picked into a stable branch, make sure to also add the

doc/development/what_requires_downtime.md

@@ -50,7 +50,7 @@ The reason we spread this out across three releases is that dropping a column is
 a destructive operation that can't be rolled back easily.
 
 Following this procedure helps us to make sure there are no deployments to GitLab.com
-and upgrade processes for self-hosted installations that lump together any of these steps.
+and upgrade processes for self-managed installations that lump together any of these steps.
 
 ### Step 1: Ignoring the column (release M)