Update Possessive.yml to error status

Move the Possessive.yml rule to error status, to satisfy a request
from Legal.

doc/.vale/gitlab/Possessive.yml

@@ -6,9 +6,9 @@
 # For a list of all options, see https://errata-ai.gitbook.io/vale/getting-started/styles
 extends: existence
 message: 'Rewrite "%s" to not use "’s".'
-level: warning
+level: error
 ignorecase: true
-link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#contractions
+link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#trademark
 tokens:
   - GitLab's  # Straight apostrophe.
   - GitLab’s  # Curly closing apostrophe.

doc/README.md

@@ -29,7 +29,7 @@ No matter how you use GitLab, we have documentation for you.
 | [**Contributing to GitLab**](#contributing-to-gitlab)<br/>At GitLab, everyone can contribute!                        | [**New to Git and GitLab?**](#new-to-git-and-gitlab)<br/>We have the resources to get you started.                         |
 | [**Build an integration with GitLab**](#build-an-integration-with-gitlab)<br/>Consult our integration documentation. | [**Coming to GitLab from another platform?**](#coming-to-gitlab-from-another-platform)<br/>Consult our guides.             |
 | [**Install GitLab**](https://about.gitlab.com/install/)<br/>Installation options for different platforms.            | [**Customers**](subscriptions/index.md)<br/>Information for new and existing customers.                                    |
-| [**Update GitLab**](update/README.md)<br/>Update your GitLab self-managed instance to the latest version.            | [**Reference Architectures**](administration/reference_architectures/index.md)<br/>GitLab's reference architectures        |
+| [**Update GitLab**](update/README.md)<br/>Update your GitLab self-managed instance to the latest version.            | [**Reference Architectures**](administration/reference_architectures/index.md)<br/>GitLab reference architectures        |
 | [**GitLab releases**](https://about.gitlab.com/releases/)<br/>What's new in GitLab.                                  |                                                                                                                            |
 
 ## Popular topics
@@ -69,8 +69,8 @@ We have the following documentation to rapidly uplift your GitLab knowledge:
 | [GitLab basics guides](gitlab-basics/README.md)                                                   | Start working on the command line and with GitLab.             |
 | [GitLab workflow overview](https://about.gitlab.com/blog/2016/10/25/gitlab-workflow-an-overview/) | Enhance your workflow with the best of GitLab Workflow.        |
 | [Get started with GitLab CI/CD](ci/quick_start/README.md)                                         | Quickly implement GitLab CI/CD.                                |
-| [Auto DevOps](topics/autodevops/index.md)                                                         | Learn more about GitLab's Auto DevOps.                         |
-| [GitLab Markdown](user/markdown.md)                                                               | GitLab's advanced formatting system (GitLab Flavored Markdown) |
+| [Auto DevOps](topics/autodevops/index.md)                                                         | Learn more about Auto DevOps in GitLab.                         |
+| [GitLab Markdown](user/markdown.md)                                                               | Advanced formatting system (GitLab Flavored Markdown) |
 
 ### User account
 

doc/architecture/blueprints/cloud_native_gitlab_pages/index.md

@@ -72,7 +72,7 @@ of complexity, maintenance cost and enormous, negative impact on availability.
 
 ## New GitLab Pages Architecture
 
-- GitLab Pages sources domains' configuration from GitLab's internal
+- GitLab Pages sources domains' configuration from the GitLab internal
   API, instead of reading `config.json` files from a local shared storage.
 - GitLab Pages serves static content from Object Storage.
 
@@ -90,7 +90,7 @@ too.
 
 ## Iterations
 
-1. ✓ Redesign GitLab Pages configuration source to use GitLab's API
+1. ✓ Redesign GitLab Pages configuration source to use the GitLab API
 1. ✓ Evaluate performance and build reliable caching mechanisms
 1. ✓ Incrementally rollout the new source on GitLab.com
 1. ✓ Make GitLab Pages API domains configuration source enabled by default

doc/development/README.md

@@ -66,13 +66,13 @@ 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 GitLab team members)
+- [Requesting access to ChatOps on GitLab.com](chatops_on_gitlabcom.md#requesting-access) (for GitLab team members)
 - [Patch release process for developers](https://gitlab.com/gitlab-org/release/docs/blob/master/general/patch/process.md#process-for-developers)
 - [Adding a new service component to GitLab](adding_service_component.md)
 
 ### Development guidelines review
 
-When you submit a change to GitLab's development guidelines, who 
+When you submit a change to the GitLab development guidelines, who
 you ask for reviews depends on the level of change.
 
 #### Wording, style, or link changes

doc/development/api_graphql_styleguide.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # GraphQL API style guide
 
-This document outlines the style guide for GitLab's [GraphQL API](../api/graphql/index.md).
+This document outlines the style guide for the GitLab [GraphQL API](../api/graphql/index.md).
 
 ## How GitLab implements GraphQL
 
@@ -19,7 +19,7 @@ which is exposed as an API endpoint at `/api/graphql`.
 ## Deep Dive
 
 In March 2019, Nick Thomas hosted a Deep Dive (GitLab team members only: `https://gitlab.com/gitlab-org/create-stage/issues/1`)
-on GitLab's [GraphQL API](../api/graphql/index.md) to share his domain specific knowledge
+on the GitLab [GraphQL API](../api/graphql/index.md) to share his domain specific knowledge
 with anyone who may work in this part of the codebase in the future. You can find the
 [recording on YouTube](https://www.youtube.com/watch?v=-9L_1MWrjkg), and the slides on
 [Google Slides](https://docs.google.com/presentation/d/1qOTxpkTdHIp1CRjuTvO-aXg0_rUtzE3ETfLUdnBB5uQ/edit)
@@ -44,7 +44,7 @@ add a `HTTP_PRIVATE_TOKEN` header.
 
 ## Global IDs
 
-GitLab's GraphQL API uses Global IDs (i.e: `"gid://gitlab/MyObject/123"`)
+The GitLab GraphQL API uses Global IDs (i.e: `"gid://gitlab/MyObject/123"`)
 and never database primary key IDs.
 
 Global ID is [a convention](https://graphql.org/learn/global-object-identification/)
@@ -154,7 +154,7 @@ Further reading:
 
 ### Exposing Global IDs
 
-In keeping with GitLab's use of [Global IDs](#global-ids), always convert
+In keeping with the GitLab use of [Global IDs](#global-ids), always convert
 database primary key IDs into Global IDs when you expose them.
 
 All fields named `id` are
@@ -403,11 +403,11 @@ end
 
 ## Deprecating fields and enum values
 
-GitLab's GraphQL API is versionless, which means we maintain backwards
+The GitLab GraphQL API is versionless, which means we maintain backwards
 compatibility with older versions of the API with every change. Rather
 than removing a field or [enum value](#enums), we need to _deprecate_ it instead.
 The deprecated parts of the schema can then be removed in a future release
-in accordance with [GitLab's deprecation process](../api/graphql/index.md#deprecation-process).
+in accordance with the [GitLab deprecation process](../api/graphql/index.md#deprecation-process).
 
 Fields and enum values are deprecated using the `deprecated` property.
 The value of the property is a `Hash` of:
@@ -1106,7 +1106,7 @@ are returned as the result of the mutation.
 
 #### Update mutation granularity
 
-GitLab's service-oriented architecture means that most mutations call a Create, Delete, or Update
+The service-oriented architecture in GitLab means that most mutations call a Create, Delete, or Update
 service, for example `UpdateMergeRequestService`.
 For Update mutations, a you might want to only update one aspect of an object, and thus only need a
 _fine-grained_ mutation, for example `MergeRequest::SetWip`.
@@ -1233,7 +1233,7 @@ These arguments automatically generate an input type called
 
 ### Object identifier arguments
 
-In keeping with GitLab's use of [Global IDs](#global-ids), mutation
+In keeping with the GitLab use of [Global IDs](#global-ids), mutation
 arguments should use Global IDs to identify an object and never database
 primary key IDs.
 
@@ -1530,7 +1530,7 @@ In the future this may be able to be done using `InputUnions` if
 [this RFC](https://github.com/graphql/graphql-spec/blob/master/rfcs/InputUnion.md)
 is merged.
 
-## GitLab's custom scalars
+## GitLab custom scalars
 
 ### `Types::TimeType`
 
@@ -1695,7 +1695,7 @@ end
 
 ## Notes about Query flow and GraphQL infrastructure
 
-GitLab's GraphQL infrastructure can be found in `lib/gitlab/graphql`.
+The GitLab GraphQL infrastructure can be found in `lib/gitlab/graphql`.
 
 [Instrumentation](https://graphql-ruby.org/queries/instrumentation.html) is functionality
 that wraps around a query being executed. It is implemented as a module that uses the `Instrumentation` class.

doc/development/architecture.md

@@ -94,7 +94,7 @@ The simplest way to ensure this, is to add support for your feature or service t
 ### Simplified component overview
 
 This is a simplified architecture diagram that can be used to
-understand GitLab's architecture.
+understand the GitLab architecture.
 
 A complete architecture diagram is available in our
 [component diagram](#component-diagram) below.

doc/development/contributing/index.md

@@ -144,7 +144,7 @@ Keep the following in mind when submitting merge requests:
 
 - When reviewers are reading through a merge request they may request guidance from other
   reviewers.
-- If the code quality is found to not meet GitLab’s standards, the merge request reviewer will
+- If the code quality is found to not meet GitLab standards, the merge request reviewer will
   provide guidance and refer the author to our:
   - [Documentation](../documentation/styleguide/index.md) style guide.
   - [Code style guides](style_guides.md).

doc/development/dangerbot.md

@@ -46,7 +46,7 @@ bin/rake danger_local
 ## Operation
 
 On startup, Danger reads a [`Dangerfile`](https://gitlab.com/gitlab-org/gitlab/blob/master/Dangerfile)
-from the project root. GitLab's Danger code is decomposed into a set of helpers
+from the project root. Danger code in GitLab is decomposed into a set of helpers
 and plugins, all within the [`danger/`](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/danger/)
 subdirectory, so ours just tells Danger to load it all. Danger then runs
 each plugin against the merge request, collecting the output from each. A plugin
@@ -66,7 +66,7 @@ continue to apply. However, there are a few things that deserve special emphasis
 Danger is a powerful tool and flexible tool, but not always the most appropriate
 way to solve a given problem or workflow.
 
-First, be aware of GitLab's [commitment to dogfooding](https://about.gitlab.com/handbook/engineering/#dogfooding).
+First, be aware of the GitLab [commitment to dogfooding](https://about.gitlab.com/handbook/engineering/#dogfooding).
 The code we write for Danger is GitLab-specific, and it **may not** be most
 appropriate place to implement functionality that addresses a need we encounter.
 Our users, customers, and even our own satellite projects, such as [Gitaly](https://gitlab.com/gitlab-org/gitaly),

doc/development/diffs.md

@@ -15,7 +15,7 @@ We rely on different sources to present diffs. These include:
 ## Deep Dive
 
 In January 2019, Oswaldo Ferreira hosted a Deep Dive (GitLab team members only:
-`https://gitlab.com/gitlab-org/create-stage/issues/1`) on GitLab's Diffs and Commenting on Diffs
+`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 [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)

doc/development/fe_guide/dependencies.md

@@ -32,7 +32,7 @@ updated using renovate are:
 
 We discourage installing some dependencies in [GitLab repository](https://gitlab.com/gitlab-org/gitlab)
 because they can create conflicts in the dependency tree. Blocked dependencies are declared in the
-`blockDependencies` property of GitLab’s [`package.json` file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/package.json).
+`blockDependencies` property of the GitLab [`package.json` file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/package.json).
 
 ## Dependency notes
 

doc/development/fe_guide/development_process.md

@@ -85,7 +85,7 @@ With the purpose of being [respectful of others' time](https://about.gitlab.com/
 ### Share your work early
 
 1. Before writing code, ensure your vision of the architecture is aligned with
-   GitLab's architecture.
+   GitLab architecture.
 1. Add a diagram to the issue and ask a frontend maintainer in the Slack channel `#frontend_maintainers` about it.
 
    ![Diagram of Issue Boards Architecture](img/boards_diagram.png)

doc/development/fe_guide/frontend_faq.md

@@ -182,7 +182,7 @@ we're using that our target browsers don't support. You don't need to add `core-
 polyfills manually.
 
 GitLab adds non-`core-js` polyfills for extending browser features (such as
-GitLab's SVG polyfill), which allow us to reference SVGs by using `<use xlink:href>`.
+the GitLab SVG polyfill), which allow us to reference SVGs by using `<use xlink:href>`.
 Be sure to add these polyfills to `app/assets/javascripts/commons/polyfills.js`.
 
 To see what polyfills are being used:

doc/development/fe_guide/index.md

@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Frontend Development Guidelines
 
 This document describes various guidelines to ensure consistency and quality
-across GitLab's frontend team.
+across the GitLab frontend team.
 
 ## Overview
 
@@ -24,7 +24,7 @@ Working with our frontend assets requires Node (v10.13.0 or greater) and Yarn
 For our currently-supported browsers, see our [requirements](../../install/requirements.md#supported-web-browsers).
 
 Use [BrowserStack](https://www.browserstack.com/) to test with our supported browsers.
-Sign in to BrowserStack with the credentials saved in the **Engineering** vault of GitLab's
+Sign in to BrowserStack with the credentials saved in the **Engineering** vault of the GitLab
 [shared 1Password account](https://about.gitlab.com/handbook/security/#1password-guide).
 
 ## Initiatives
@@ -41,7 +41,7 @@ How we [plan and execute](development_process.md) the work on the frontend.
 
 ## Architecture
 
-How we go about [making fundamental design decisions](architecture.md) in GitLab's frontend team
+How we go about [making fundamental design decisions](architecture.md) in the GitLab frontend team
 or make changes to our frontend development guidelines.
 
 ## Testing
@@ -56,7 +56,7 @@ Reusable components with technical and usage guidelines can be found in our
 
 ## Design Patterns
 
-Common JavaScript [design patterns](design_patterns.md) in GitLab's codebase.
+Common JavaScript [design patterns](design_patterns.md) in the GitLab codebase.
 
 ## Vue.js Best Practices
 

doc/development/graphql_guide/index.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # GraphQL development guidelines
 
-This guide contains all the information to successfully contribute to GitLab's
+This guide contains all the information to successfully contribute to the GitLab
 GraphQL API. This is a living document, and we welcome contributions,
 feedback, and suggestions.
 

doc/development/import_project.md

@@ -23,7 +23,7 @@ The first option is to simply [import the Project tarball file via the GitLab UI
 
 It should take up to 15 minutes for the project to fully import. You can head to the project's main page for the current status.
 
-This method ignores all the errors silently (including the ones related to `GITALY_DISABLE_REQUEST_LIMITS`) and is used by GitLab's users. For development and testing, check the other methods below.
+This method ignores all the errors silently (including the ones related to `GITALY_DISABLE_REQUEST_LIMITS`) and is used by GitLab users. For development and testing, check the other methods below.
 
 ### Importing via the `import-project` script
 

doc/development/new_fe_guide/index.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Frontend Development Guidelines
 
-This guide contains all the information to successfully contribute to GitLab's frontend.
+This guide contains all the information to successfully contribute to the GitLab frontend.
 This is a living document, and we welcome contributions, feedback, and suggestions.
 
 ## [Development](development/index.md)

doc/development/performance.md

@@ -305,7 +305,7 @@ bundle exec stackprof --stackcollapse /tmp/stackprof.55769.c6c3906452.profile |
 
 ## RSpec profiling
 
-GitLab's development environment also includes the
+The GitLab development environment also includes the
 [rspec_profiling](https://github.com/foraker/rspec_profiling) gem, which is used
 to collect data on spec execution times. This is useful for analyzing the
 performance of the test suite itself, or seeing how the performance of a spec
@@ -358,7 +358,7 @@ We can use two approaches, often in combination, to track down memory issues:
 
 We can use `memory_profiler` for profiling.
 
-The [`memory_profiler`](https://github.com/SamSaffron/memory_profiler) gem is already present in GitLab's `Gemfile`,
+The [`memory_profiler`](https://github.com/SamSaffron/memory_profiler) gem is already present in the GitLab `Gemfile`,
 you just need to require it:
 
 ```ruby

doc/development/pipelines.md

@@ -457,7 +457,7 @@ Consult the [Review Apps](testing_guide/review_apps.md) dedicated page for more
 
 ### As-if-FOSS jobs
 
-The `* as-if-foss` jobs allows to run GitLab's test suite "as-if-FOSS", meaning as if the jobs would run in the context
+The `* as-if-foss` jobs allows the GitLab test suite "as-if-FOSS", meaning as if the jobs would run in the context
 of the `gitlab-org/gitlab-foss` project. These jobs are only created in the following cases:
 
 - `gitlab-org/security/gitlab` merge requests.

doc/development/repository_mirroring.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 ## Deep Dive
 
 In December 2018, Tiago Botelho hosted a Deep Dive (GitLab team members only: `https://gitlab.com/gitlab-org/create-stage/issues/1`)
-on GitLab's [Pull Repository Mirroring functionality](../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository)
+on the GitLab [Pull Repository Mirroring functionality](../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository)
 to share his domain specific knowledge with anyone who may work in this part of the
 codebase in the future. You can find the [recording on YouTube](https://www.youtube.com/watch?v=sSZq0fpdY-Y),
 and the slides in [PDF](https://gitlab.com/gitlab-org/create-stage/uploads/8693404888a941fd851f8a8ecdec9675/Gitlab_Create_-_Pull_Mirroring_Deep_Dive.pdf).

doc/development/testing_guide/end_to_end/page_objects.md

@@ -22,7 +22,7 @@ fields.
 ## Why do we need that?
 
 We need page objects because we need to reduce duplication and avoid problems
-whenever someone changes some selectors in GitLab's source code.
+whenever someone changes some selectors in the GitLab source code.
 
 Imagine that we have a hundred specs in GitLab QA, and we need to sign into
 GitLab each time, before we make assertions. Without a page object, one would

doc/development/testing_guide/end_to_end/rspec_metadata_tests.md

@@ -18,7 +18,7 @@ This is a partial list of the [RSpec metadata](https://relishapp.com/rspec/rspec
 | `:jira`           | The test requires a Jira Server. [GitLab-QA](https://gitlab.com/gitlab-org/gitlab-qa) provisions the Jira Server in a Docker container when the `Test::Integration::Jira` test scenario is run.
 | `:kubernetes`     | The test includes a GitLab instance that is configured to be run behind an SSH tunnel, allowing a TLS-accessible GitLab. This test also includes provisioning of at least one Kubernetes cluster to test against. _This tag is often be paired with `:orchestrated`._ |
 | `:only`           | The test is only to be run against specific environments or pipelines. See [Environment selection](environment_selection.md) for more information. |
-| `:orchestrated`   | The GitLab instance under test may be [configured by `gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/what_tests_can_be_run.md#orchestrated-tests) to be different to the default GitLab configuration, or `gitlab-qa` may launch additional services in separate Docker containers, or both. Tests tagged with `:orchestrated` are excluded when testing environments where we can't dynamically modify GitLab's configuration (for example, Staging). |
+| `:orchestrated`   | The GitLab instance under test may be [configured by `gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/what_tests_can_be_run.md#orchestrated-tests) to be different to the default GitLab configuration, or `gitlab-qa` may launch additional services in separate Docker containers, or both. Tests tagged with `:orchestrated` are excluded when testing environments where we can't dynamically modify the GitLab configuration (for example, Staging). |
 | `:quarantine`     | The test has been [quarantined](https://about.gitlab.com/handbook/engineering/quality/guidelines/debugging-qa-test-failures/#quarantining-tests), runs in a separate job that only includes quarantined tests, and is allowed to fail. The test is skipped in its regular job so that if it fails it doesn't hold up the pipeline. Note that you can also [quarantine a test only when it runs against specific environment](environment_selection.md#quarantining-a-test-for-a-specific-environment). |
 | `:reliable`       | The test has been [promoted to a reliable test](https://about.gitlab.com/handbook/engineering/quality/guidelines/reliable-tests/#promoting-an-existing-test-to-reliable) meaning it passes consistently in all pipelines, including merge requests. |
 | `:requires_admin` | The test requires an admin account. Tests with the tag are excluded when run against Canary and Production environments. |

doc/development/testing_guide/frontend_testing.md

@@ -1088,7 +1088,7 @@ Some regressions only affect a specific browser version. We can install and test
 
 [BrowserStack](https://www.browserstack.com/) allows you to test more than 1200 mobile devices and browsers.
 You can use it directly through the [live app](https://www.browserstack.com/live) or you can install the [chrome extension](https://chrome.google.com/webstore/detail/browserstack/nkihdmlheodkdfojglpcjjmioefjahjb) for easy access.
-Sign in to BrowserStack with the credentials saved in the **Engineering** vault of GitLab's
+Sign in to BrowserStack with the credentials saved in the **Engineering** vault of the GitLab
 [shared 1Password account](https://about.gitlab.com/handbook/security/#1password-guide).
 
 ### Firefox

doc/development/testing_guide/review_apps.md

@@ -102,8 +102,8 @@ subgraph "CNG-mirror pipeline"
 - The manual `review-stop` can be used to
   stop a Review App manually, and is also started by GitLab once a merge
   request's branch is deleted after being merged.
-- The Kubernetes cluster is connected to the `gitlab` projects using
-  [GitLab's Kubernetes integration](../../user/project/clusters/index.md). This basically
+- The Kubernetes cluster is connected to the `gitlab` projects using the
+  [GitLab Kubernetes integration](../../user/project/clusters/index.md). This basically
   allows to have a link to the Review App directly from the merge request widget.
 
 ### Auto-stopping of Review Apps

doc/development/windows.md

@@ -13,7 +13,7 @@ This is a guide for how to get a Windows development virtual machine on Google C
 
 ## Why Windows in Google Cloud?
 
-Use of Microsoft Windows operating systems on company laptops is banned under GitLab's [Approved Operating Systems policy](https://about.gitlab.com/handbook/security/approved_os.html#windows).
+Use of Microsoft Windows operating systems on company laptops is banned under the GitLab [Approved Operating Systems policy](https://about.gitlab.com/handbook/security/approved_os.html#windows).
 
 This can make it difficult to develop features for the Windows platforms. Using GCP allows us to have a temporary Windows machine that can be removed once we're done with it.
 

doc/raketasks/backup_restore.md

@@ -627,7 +627,7 @@ backups are copied to, and is created if it does not exist. If the
 directory that you want to copy the tarballs to is the root of your mounted
 directory, use `.` instead.
 
-Because file system performance may affect GitLab's overall performance,
+Because file system performance may affect overall GitLab performance,
 [GitLab doesn't recommend using EFS for storage](../administration/nfs.md#avoid-using-awss-elastic-file-system-efs).
 
 For Omnibus GitLab packages:
@@ -671,7 +671,7 @@ For installations from source:
 
 The backup archives created by GitLab (`1393513186_2014_02_27_gitlab_backup.tar`)
 have the owner/group `git`/`git` and 0600 permissions by default. This is
-meant to avoid other system users reading GitLab's data. If you need the backup
+meant to avoid other system users reading GitLab data. If you need the backup
 archives to have different permissions, you can use the `archive_permissions`
 setting.
 

doc/raketasks/user_management.md

@@ -86,7 +86,7 @@ block_auto_created_users: false
 ## Disable two-factor authentication for all users
 
 This task disables two-factor authentication (2FA) for all users that have it enabled. This can be
-useful if GitLab's `config/secrets.yml` file has been lost and users are unable
+useful if the GitLab `config/secrets.yml` file has been lost and users are unable
 to log in, for example.
 
 To disable two-factor authentication for all users, run:

doc/subscriptions/gitlab_com/index.md

@@ -234,7 +234,7 @@ If you renew or upgrade, your data is accessible again.
 ## CI pipeline minutes
 
 CI pipeline minutes are the execution time for your
-[pipelines](../../ci/pipelines/index.md) on GitLab's shared runners. Each
+[pipelines](../../ci/pipelines/index.md) on GitLab shared runners. Each
 [GitLab.com tier](https://about.gitlab.com/pricing/) includes a monthly quota
 of CI pipeline minutes:
 

doc/subscriptions/index.md

@@ -27,7 +27,7 @@ When choosing a subscription, there are two factors to consider:
 There are some differences in how a subscription applies, depending if you use
 GitLab.com or a self-managed instance:
 
-- [GitLab.com](gitlab_com/index.md): GitLab's software-as-a-service offering.
+- [GitLab.com](gitlab_com/index.md): The GitLab software-as-a-service offering.
   You don't need to install anything to use GitLab.com, you only need to
   [sign up](https://gitlab.com/users/sign_up) and start using GitLab straight away.
 - [GitLab self-managed](self_managed/index.md): Install, administer, and maintain

doc/topics/application_development_platform/index.md

@@ -42,7 +42,7 @@ with various cloud providers.
 
 In order to provide modern DevOps workflows, our Application Development Platform relies on
 [Auto DevOps](../autodevops/index.md) to provide those workflows. Auto DevOps works with
-any Kubernetes cluster; you're not limited to running on GitLab's infrastructure. Additionally, Auto DevOps offers
+any Kubernetes cluster; you're not limited to running on GitLab infrastructure. Additionally, Auto DevOps offers
 an incremental consumption path. Because it is [composable](../autodevops/customize.md#using-components-of-auto-devops),
 you can use as much or as little of the default pipeline as you'd like, and deeply customize without having to integrate a completely different platform.
 

doc/topics/autodevops/stages.md

@@ -12,7 +12,7 @@ Read them carefully to understand how each one works.
 ## Auto Build
 
 NOTE:
-Auto Build is not supported if Docker in Docker is not available for your GitLab Runners, like in OpenShift clusters. GitLab's OpenShift support is tracked [in a dedicated epic](https://gitlab.com/groups/gitlab-org/-/epics/2068).
+Auto Build is not supported if Docker in Docker is not available for your GitLab Runners, like in OpenShift clusters. The OpenShift support in GitLab is tracked [in a dedicated epic](https://gitlab.com/groups/gitlab-org/-/epics/2068).
 
 Auto Build creates a build of the application using an existing `Dockerfile` or
 Heroku buildpacks. The resulting Docker image is pushed to the

doc/topics/git/feature_branch_development.md

@@ -15,7 +15,7 @@ Once work on the development branch is complete, then the feature branch can be
 
 GitLab frequently implements this process whenever there is an MVC that requires multiple MRs.
 
-## Use case: GitLab's release posts
+## Use case: GitLab release posts
 
 This section describes the use case with GitLab [release posts](https://about.gitlab.com/handbook/marketing/blog/release-posts/).
 Dozens of GitLab team members contribute to each monthly release post.

doc/topics/git/lfs/migrate_to_git_lfs.md

@@ -176,8 +176,8 @@ but commented out to help encourage others to add to it in the future. -->
 
 - [Getting Started with Git LFS](https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/)
 - [Migrate from Git Annex to Git LFS](migrate_from_git_annex_to_git_lfs.md)
-- [GitLab's Git LFS user documentation](index.md)
-- [GitLab's Git LFS administrator documentation](../../../administration/lfs/index.md)
+- [GitLab Git LFS user documentation](index.md)
+- [GitLab Git LFS administrator documentation](../../../administration/lfs/index.md)
 - Alternative method to [migrate an existing repository to Git LFS](https://github.com/git-lfs/git-lfs/wiki/Tutorial#migrating-existing-repository-data-to-lfs)
 
 <!--

doc/topics/index.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 Welcome to Topics! We have organized our content resources into topics
 to get you started on areas of your interest. Each topic page
 consists of an index listing all related content. It guides
-you through better understanding GitLab's concepts
+you through better understanding GitLab concepts
 through our regular docs, and, when available, through articles (guides,
 tutorials, technical overviews, blog posts) and videos.
 

doc/university/README.md

@@ -51,7 +51,7 @@ The GitLab University curriculum is composed of GitLab videos, screencasts, pres
 1. [Creating a Project in GitLab - Video](https://www.youtube.com/watch?v=7p0hrpNaJ14)
 1. [How to Create Files and Directories](https://about.gitlab.com/blog/2016/02/10/feature-highlight-create-files-and-directories-from-files-page/)
 1. [GitLab To-Do List](https://about.gitlab.com/blog/2016/03/02/gitlab-todos-feature-highlight/)
-1. [GitLab's Work in Progress (WIP) Flag](https://about.gitlab.com/blog/2016/01/08/feature-highlight-wip/)
+1. [GitLab Work in Progress (WIP) Flag](https://about.gitlab.com/blog/2016/01/08/feature-highlight-wip/)
 
 ### 1.5. Migrating from other Source Control
 

doc/update/upgrading_postgresql_using_slony.md

@@ -36,7 +36,7 @@ command on your active database server:
 sudo -u gitlab-psql /opt/gitlab/embedded/bin/pg_dump -h /var/opt/gitlab/postgresql -p 5432 -U gitlab-psql -s -f /tmp/structure.sql gitlabhq_production
 ```
 
-If you're not using GitLab's Omnibus package you may have to adjust the paths to
+If you're not using the Omnibus GitLab package you may have to adjust the paths to
 `pg_dump` and the PostgreSQL installation directory to match the paths of your
 configuration.
 

doc/user/admin_area/analytics/dev_ops_report.md

@@ -20,9 +20,9 @@ To see DevOps Report, go to **Admin Area > Analytics > DevOps Report**.
 NOTE:
 Your GitLab instance's [usage ping](../settings/usage_statistics.md#usage-ping) must be activated in order to use this feature.
 
-The DevOps Score tab displays the usage of GitLab's major features on your instance over
+The DevOps Score tab displays the usage of major GitLab features on your instance over
 the last 30 days, averaged over the number of billable users in that time period. It also
-provides a Lead score per feature, which is calculated based on GitLab's analysis
+provides a Lead score per feature, which is calculated based on GitLab analysis
 of top-performing instances based on [usage ping data](../settings/usage_statistics.md#usage-ping) that GitLab has
 collected. Your score is compared to the lead score of each feature and then expressed as a percentage at the bottom of said feature.
 Your overall **DevOps Score** is an average of your feature scores. You can use this score to compare your DevOps status to other organizations.
@@ -32,7 +32,7 @@ Your overall **DevOps Score** is an average of your feature scores. You can use
 The page also provides helpful links to articles and GitLab docs, to help you
 improve your scores.
 
-Usage ping data is aggregated on GitLab's servers for analysis. Your usage
+Usage ping data is aggregated on GitLab servers for analysis. Your usage
 information is **not sent** to any other GitLab instances. If you have just started using GitLab, it may take a few weeks for data to be
 collected before this feature is available.
 
@@ -40,7 +40,7 @@ collected before this feature is available.
 
 [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/247112) in GitLab 13.7.
 
-The DevOps Adoption tab shows you which segments of your organization are using GitLab's most essential features:
+The DevOps Adoption tab shows you which segments of your organization are using the most essential features of GitLab:
 
 - Issues
 - Merge Requests

doc/user/admin_area/index.md

@@ -37,7 +37,7 @@ The Admin Area is made up of the following sections:
 | **{lock}** Credentials **(ULTIMATE ONLY)**     | View [credentials](credentials_inventory.md) that can be used to access your instance.                                                                                                                                                                                                   |
 | **{template}** Service Templates               | Create [service templates](../project/integrations/services_templates.md) for projects.                                                                                                                                                                                                  |
 | **{labels}** Labels                            | Create and maintain [labels](labels.md) for your GitLab instance.                                                                                                                                                                                                                        |
-| **{appearance}** Appearance                    | Customize [GitLab's appearance](appearance.md).                                                                                                                                                                                                                                          |
+| **{appearance}** Appearance                    | Customize [GitLab appearance](appearance.md).                                                                                                                                                                                                                                          |
 | **{settings}** Settings                        | Modify the [settings](settings/index.md) for your GitLab instance.                                                                                                                                                                                                                       |
 
 ## Admin Dashboard

doc/user/admin_area/settings/external_authorization.md

@@ -40,7 +40,7 @@ the [Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/logs
 
 ## Configuration
 
-The external authorization service can be enabled by an admin on the GitLab's
+The external authorization service can be enabled by an administrator on the GitLab
 **Admin Area > Settings > General** page:
 
 ![Enable external authorization service](img/external_authorization_service_settings.png)

doc/user/admin_area/settings/index.md

@@ -65,7 +65,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
 | ------ | ----------- |
 | [Continuous Integration and Deployment](continuous_integration.md) | Auto DevOps, runners and job artifacts. |
 | [Required pipeline configuration](continuous_integration.md#required-pipeline-configuration) **(PREMIUM ONLY)** | Set an instance-wide auto included [pipeline configuration](../../../ci/yaml/README.md). This pipeline configuration is run after the project's own configuration. |
-| [Package Registry](continuous_integration.md#package-registry-configuration) | Settings related to the use and experience of using GitLab's Package Registry. Note there are [risks involved](../../packages/container_registry/index.md#use-with-external-container-registries) in enabling some of these settings. |
+| [Package Registry](continuous_integration.md#package-registry-configuration) | Settings related to the use and experience of using the GitLab Package Registry. Note there are [risks involved](../../packages/container_registry/index.md#use-with-external-container-registries) in enabling some of these settings. |
 
 ## Reporting
 

doc/user/application_security/api_fuzzing/index.md

@@ -734,7 +734,7 @@ faults it reports.
 ## Viewing fuzzing faults
 
 The API Fuzzing analyzer produces a JSON report that is collected and used
-[to populate the faults into GitLab's vulnerability screens](../index.md#view-details-of-an-api-fuzzing-vulnerability).
+[to populate the faults into GitLab vulnerability screens](../index.md#view-details-of-an-api-fuzzing-vulnerability).
 Fuzzing faults show up as vulnerabilities with a severity of Unknown.
 
 The faults that API fuzzing finds require manual investigation and aren't associated with a specific

doc/user/application_security/index.md

@@ -110,7 +110,7 @@ The scanning tools and vulnerabilities database are updated regularly.
 | Secure scanning tool                                         | Vulnerabilities database updates          |
 |:-------------------------------------------------------------|-------------------------------------------|
 | [Container Scanning](container_scanning/index.md)            | Uses `clair`. The latest `clair-db` version is used for each job by running the [`latest` Docker image tag](https://gitlab.com/gitlab-org/gitlab/blob/438a0a56dc0882f22bdd82e700554525f552d91b/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L37). The `clair-db` database [is updated daily according to the author](https://github.com/arminc/clair-local-scan#clair-server-or-local). |
-| [Dependency Scanning](dependency_scanning/index.md)          | Relies on `bundler-audit` (for Ruby gems), `retire.js` (for NPM packages), and `gemnasium` (GitLab's own tool for all libraries). Both `bundler-audit` and `retire.js` fetch their vulnerabilities data from GitHub repositories, so vulnerabilities added to `ruby-advisory-db` and `retire.js` are immediately available. The tools themselves are updated once per month if there's a new version. The [Gemnasium DB](https://gitlab.com/gitlab-org/security-products/gemnasium-db) is updated at least once a week. See our [current measurement of time from CVE being issued to our product being updated](https://about.gitlab.com/handbook/engineering/development/performance-indicators/#cve-issue-to-update). |
+| [Dependency Scanning](dependency_scanning/index.md)          | Relies on `bundler-audit` (for Ruby gems), `retire.js` (for NPM packages), and `gemnasium` (the GitLab tool for all libraries). Both `bundler-audit` and `retire.js` fetch their vulnerabilities data from GitHub repositories, so vulnerabilities added to `ruby-advisory-db` and `retire.js` are immediately available. The tools themselves are updated once per month if there's a new version. The [Gemnasium DB](https://gitlab.com/gitlab-org/security-products/gemnasium-db) is updated at least once a week. See our [current measurement of time from CVE being issued to our product being updated](https://about.gitlab.com/handbook/engineering/development/performance-indicators/#cve-issue-to-update). |
 | [Dynamic Application Security Testing (DAST)](dast/index.md) | The scanning engine is updated on a periodic basis. See the [version of the underlying tool `zaproxy`](https://gitlab.com/gitlab-org/security-products/dast/blob/master/Dockerfile#L1). The scanning rules are downloaded at scan runtime. |
 | [Static Application Security Testing (SAST)](sast/index.md)  | Relies exclusively on [the tools GitLab wraps](sast/index.md#supported-languages-and-frameworks). The underlying analyzers are updated at least once per month if a relevant update is available. The vulnerabilities database is updated by the upstream tools. |
 

doc/user/profile/preferences.md

@@ -92,7 +92,7 @@ which apply to the entire Web IDE screen.
 
 ## Behavior
 
-The following settings allow you to customize the behavior of GitLab's layout
+The following settings allow you to customize the behavior of the GitLab layout
 and default views of your dashboard and the projects' landing pages.
 
 ### Layout width