Rewrite GitLab possessives in Access, Product Analytics, Dev docs

doc/administration/auth/ldap/index.md

@@ -67,7 +67,7 @@ in the application settings.
 When a user signs in to GitLab with LDAP for the first time, and their LDAP
 email address is the primary email address of an existing GitLab user, then
 the LDAP DN is associated with the existing user. If the LDAP email
-attribute is not found in GitLab's database, a new user is created.
+attribute is not found in the GitLab user database, a new user is created.
 In other words, if an existing GitLab user wants to enable LDAP sign-in for
 themselves, they should check that their GitLab email address matches their

doc/administration/feature_flags.md

@@ -18,7 +18,7 @@ flags for a [number of reasons](../development/feature_flags/process.md#when-to-
 - To test the feature.
 - To get feedback from users and customers while in an early stage of the development of the feature.
 - To evaluate users adoption.
-- To evaluate how it impacts GitLab's performance.
+- To evaluate how it impacts the performance of GitLab.
 - To build it in smaller pieces throughout releases.
 Features behind flags can be gradually rolled out, typically:

doc/administration/troubleshooting/group_saml_scim.md

@@ -9,7 +9,7 @@ type: reference
 These are notes and screenshots regarding Group SAML and SCIM that the GitLab Support Team sometimes uses while troubleshooting, but which do not fit into the official documentation. GitLab is making this public, so that anyone can make use of the Support team’s collected knowledge.
-Please refer to GitLab's [Group SAML](../../user/group/saml_sso/index.md) docs for information on the feature and how to set it up.
+Please refer to the GitLab [Group SAML](../../user/group/saml_sso/index.md) docs for information on the feature and how to set it up.
 When troubleshooting a SAML configuration, GitLab team members will frequently start with the [SAML troubleshooting section](../../user/group/saml_sso/index.md#troubleshooting).

doc/api/appearance.md

@@ -8,8 +8,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/16647) in GitLab 12.7.
-Appearance API allows you to maintain GitLab's appearance as if using the GitLab UI at
-`/admin/appearance`. The API requires administrator privileges.
+The appearance API allows you to maintain the appearance of GitLab as if
+you're using the GitLab UI at `/admin/appearance`. The API requires
+administrator privileges.
 ## Get current appearance configuration

doc/development/README.md

@@ -16,13 +16,13 @@ Content specific to the GitLab Team should instead be included in the [Handbook]
 For information on using GitLab to work on your own software projects, see the [GitLab user documentation](../user/index.md).
-For information on working with GitLab's API, see the [API documentation](../api/README.md).
+For information on working with the GitLab APIs, see the [API documentation](../api/README.md).
 For information on how to install, configure, update, and upgrade your own GitLab instance, see the [administration documentation](../administration/index.md).
 ## Get started
-- Set up GitLab's development environment with [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/master/README.md)
+- Set up the GitLab development environment with [GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/master/README.md)
 - [GitLab contributing guide](contributing/index.md)
   - [Issues workflow](contributing/issue_workflow.md) for more information on:
     - Issue tracker guidelines.
@@ -66,7 +66,7 @@ Complementary reads:
 ### Development guidelines review
-When you submit a change to GitLab's development guidelines, request a review
+When you submit a change to the GitLab development guidelines, request a review
 from:
 - A member of your team or group, to check for technical accuracy.

doc/development/contributing/issue_workflow.md

@@ -410,8 +410,8 @@ in the regression issue as fixes are addressed.
 ## Technical and UX debt
-In order to track things that can be improved in GitLab's codebase,
-we use the ~"technical debt" label in [GitLab's issue tracker](https://gitlab.com/gitlab-org/gitlab/-/issues).
+In order to track things that can be improved in the GitLab codebase,
+we use the ~"technical debt" label in the [GitLab issue tracker](https://gitlab.com/gitlab-org/gitlab/-/issues).
 For missed user experience requirements, we use the ~"UX debt" label.
 These labels should be added to issues that describe things that can be improved,

doc/development/contributing/merge_request_workflow.md

@@ -219,7 +219,7 @@ the contribution acceptance criteria below:
    instructions for help if the "license-finder" test fails with a
    `Dependencies that need approval` error. Also, make the reviewer aware of the new
    library and explain why you need it.
-1. The merge request meets GitLab's [definition of done](#definition-of-done), below.
+1. The merge request meets the GitLab [definition of done](#definition-of-done), below.
 ## Definition of done

doc/development/documentation/restful_api_styleguide.md

@@ -3,7 +3,7 @@ type: reference, dev
 stage: none
 group: Development
 info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments-to-development-guidelines"
-description: "Writing styles, markup, formatting, and other standards for GitLab's RESTful APIs."
+description: "Writing styles, markup, formatting, and other standards for the GitLab RESTful APIs."
 ---
 # RESTful API

doc/development/fe_guide/graphql.md

@@ -143,7 +143,7 @@ More about fragments:
 ## Global IDs
-GitLab's GraphQL API expresses `id` fields as Global IDs rather than the PostgreSQL
+The GitLab GraphQL API expresses `id` fields as Global IDs rather than the PostgreSQL
 primary key `id`. Global ID is [a convention](https://graphql.org/learn/global-object-identification/)
 used for caching and fetching in client-side libraries.
@@ -411,7 +411,7 @@ handleClick() {
 ### Working with pagination
-GitLab's GraphQL API uses [Relay-style cursor pagination](https://www.apollographql.com/docs/react/pagination/overview/#cursor-based)
+The GitLab GraphQL API uses [Relay-style cursor pagination](https://www.apollographql.com/docs/react/pagination/overview/#cursor-based)
 for connection types. This means a "cursor" is used to keep track of where in the data
 set the next items should be fetched from. [GraphQL Ruby Connection Concepts](https://graphql-ruby.org/pagination/connection_concepts.html)
 is a good overview and introduction to connections.
@@ -1200,7 +1200,7 @@ describe('My Index test with `createMockApollo`', () => {
 ## Handling errors
-GitLab's GraphQL mutations currently have two distinct error modes: [Top-level](#top-level-errors) and [errors-as-data](#errors-as-data).
+The GitLab GraphQL mutations currently have two distinct error modes: [Top-level](#top-level-errors) and [errors-as-data](#errors-as-data).
 When utilising a GraphQL mutation, we must consider handling **both of these error modes** to ensure that the user receives the appropriate feedback when an error occurs.

doc/development/feature_flags/controls.md

@@ -34,7 +34,7 @@ _before_ the code is being deployed.
 This allows you to separate rolling out a feature from a deploy, making it
 easier to measure the impact of both separately.
-GitLab's feature library (using
+The GitLab feature library (using
 [Flipper](https://github.com/jnunemaker/flipper), and covered in the [Feature
 Flags process](process.md) guide) supports rolling out changes to a percentage of
 time to users. This in turn can be controlled using [GitLab Chatops](../../ci/chatops/README.md).
@@ -238,7 +238,7 @@ The issue is created in the
 project, and it will at minimum log the Slack handle of person enabling
 a feature flag, the time, and the name of the flag being changed.
-The issue is then also posted to GitLab's internal
+The issue is then also posted to the GitLab internal
 [Grafana dashboard](https://dashboards.gitlab.net/) as an annotation
 marker to make the change even more visible.

doc/development/feature_flags/development.md

@@ -46,11 +46,11 @@ This is the default type used when calling `Feature.enabled?`.
 ### `ops` type
 `ops` feature flags are long-lived feature flags that control operational aspects
-of GitLab's behavior. For example, feature flags that disable features that might
+of GitLab product behavior. For example, feature flags that disable features that might
 have a performance impact, like special Sidekiq worker behavior.
 `ops` feature flags likely do not have rollout issues, as it is hard to
-predict when they will be enabled or disabled.
+predict when they are enabled or disabled.
 To use `ops` feature flags, you must append `type: :ops` to `Feature.enabled?`
 invocations:

doc/development/feature_flags/index.md

@@ -11,13 +11,13 @@ they are new features or performance improvements. By using feature flags,
 you can determine the impact of GitLab-directed changes, while still being able
 to disable those changes without having to revert an entire release.
-Before using feature flags for GitLab's development, review the following development guides:
+Before using feature flags for GitLab development, review the following development guides:
 NOTE:
 The feature flags used by GitLab to deploy its own features **are not** the same
 as the [feature flags offered as part of the product](../../operations/feature_flags.md).
-For an overview about starting with feature flags in GitLab's development,
+For an overview about starting with feature flags in GitLab development,
 use this [training template](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/.gitlab/issue_templates/feature-flag-training.md).
 Development guides:

doc/development/product_analytics/snowplow.md

@@ -71,8 +71,8 @@ The following example shows a basic request/response flow between the following
 - Snowplow JS / Ruby Trackers on GitLab.com
 - [GitLab.com Snowplow Collector](https://gitlab.com/gitlab-com/gl-infra/readiness/-/blob/master/library/snowplow/index.md)
-- GitLab's S3 Bucket
-- GitLab's Snowflake Data Warehouse
+- The GitLab S3 Bucket
+- The GitLab Snowflake Data Warehouse
 - Sisense:
 ```mermaid
@@ -465,7 +465,7 @@ Snowplow Micro is a Docker-based solution for testing frontend and backend event
    ```ruby
    Gitlab::Tracking.self_describing_event('iglu:com.gitlab/pageview_context/jsonschema/1-0-0', data: { page_type: 'MY_TYPE' }, context: nil)
    ```
-   
+
 1. Navigate to `localhost:9090/micro/good` to see the event.
 ### Snowplow Mini

doc/development/product_analytics/usage_ping.md

@@ -80,7 +80,7 @@ production: &base
 ## Usage Ping request flow
-The following example shows a basic request/response flow between a GitLab instance, the Versions Application, the License Application, Salesforce, GitLab's S3 Bucket, GitLab's Snowflake Data Warehouse, and Sisense:
+The following example shows a basic request/response flow between a GitLab instance, the Versions Application, the License Application, Salesforce, the GitLab S3 Bucket, the GitLab Snowflake Data Warehouse, and Sisense:
 ```mermaid
 sequenceDiagram

doc/development/testing_guide/best_practices.md

@@ -448,7 +448,7 @@ instead of 30+ seconds in case of a regular `spec_helper`.
 ### `subject` and `let` variables
-GitLab's RSpec suite has made extensive use of `let`(along with its strict, non-lazy
+The GitLab RSpec suite has made extensive use of `let`(along with its strict, non-lazy
 version `let!`) variables to reduce duplication. However, this sometimes [comes at the cost of clarity](https://thoughtbot.com/blog/lets-not),
 so we need to set some guidelines for their use going forward:

doc/integration/kerberos.md

@@ -162,7 +162,7 @@ enabled, your users will be linked to their LDAP accounts on their first sign-in
 For this to work, some prerequisites must be met:
 The Kerberos username must match the LDAP user's UID. You can choose which LDAP
-attribute is used as the UID in GitLab's [LDAP configuration](../administration/auth/ldap/index.md#configuration)
+attribute is used as the UID in the GitLab [LDAP configuration](../administration/auth/ldap/index.md#configuration)
 but for Active Directory, this should be `sAMAccountName`.
 The Kerberos realm must match the domain part of the LDAP user's Distinguished

doc/ssh/README.md

@@ -234,8 +234,9 @@ key starting with `ssh-ed25519` (or `ssh-rsa`) and ending with your email addres
 ## Testing that everything is set up correctly
-To test whether your SSH key was added correctly, run the following command in
-your terminal (replacing `gitlab.com` with your GitLab's instance domain):
+To test whether your SSH key was added correctly, run the following
+command in your terminal (replace `gitlab.com` with the domain of
+your GitLab instance):
 ```shell
 ssh -T git@gitlab.com
@@ -260,8 +261,8 @@ section to make sure you're connecting to the correct server. For example, you c
 the ECDSA key fingerprint shown above in the linked section.
 Once added to the list of known hosts, you should validate the
-authenticity of GitLab's host again. Run the above command once more, and
-you should only receive a _Welcome to GitLab, `@username`!_ message.
+authenticity of the GitLab host, once again. Run the above command
+again, and you should receive a _Welcome to GitLab, `@username`!_ message.
 If the welcome message doesn't appear, you can troubleshoot the problem by running `ssh`
 in verbose mode with the following command:

doc/user/group/saml_sso/scim_setup.md

@@ -13,7 +13,7 @@ System for Cross-domain Identity Management (SCIM), is an open standard that ena
 automation of user provisioning. When SCIM is provisioned for a GitLab group, membership of
 that group is synchronized between GitLab and the identity provider.
-GitLab's [SCIM API](../../../api/scim.md) implements part of [the RFC7644 protocol](https://tools.ietf.org/html/rfc7644).
+The GitLab [SCIM API](../../../api/scim.md) implements part of [the RFC7644 protocol](https://tools.ietf.org/html/rfc7644).
 ## Features
@@ -240,7 +240,7 @@ To see how the `external_uid` compares to the value returned as the SAML NameId,
 Whether the value was changed or you need to map to a different field, ensure `id`, `externalId`, and `NameId` all map to the same field.
-If GitLab's `externalId` doesn't match the SAML NameId, it will need to be updated in order for the user to log in. Ideally your identity provider will be configured to do such an update, but in some cases it may be unable to do so, such as when looking up a user fails due to an ID change.
+If the GitLab `externalId` doesn't match the SAML NameId, it needs to be updated in order for the user to sign in. Ideally your identity provider is configured to do such an update, but in some cases it may be unable to do so, such as when looking up a user fails due to an ID change.
 Be cautious if you revise the fields used by your SCIM identity provider, typically `id` and `externalId`.
 We use these IDs to look up users. If the identity provider does not know the current values for these fields,

doc/user/profile/account/two_factor_authentication.md

@@ -277,7 +277,7 @@ applications and U2F / WebAuthn devices.
 When 2FA is enabled, you can no longer use your normal account password to
 authenticate with Git over HTTPS on the command line or when using
-[GitLab's API](../../../api/README.md). You must use a
+the [GitLab API](../../../api/README.md). You must use a
 [personal access token](../personal_access_tokens.md) instead.
 ## Recovery options