Merge branch 'doc/clean_up_doc_warning_latin_276202_5' into 'master'

Fix up the docs warning detected by the vale latin term rule PART 5

See merge request gitlab-org/gitlab!66326

doc/development/fe_guide/style/html.md

@@ -62,7 +62,7 @@ Avoid forcing links to open in a new window as this reduces the control the user
 However, it might be a good idea to use a blank target when replacing the current page with
 the link makes the user lose content or progress.
 
-Use `rel="noopener noreferrer"` whenever your links open in a new window, i.e. `target="_blank"`. This prevents a security vulnerability [documented by JitBit](https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/).
+Use `rel="noopener noreferrer"` whenever your links open in a new window, that is, `target="_blank"`. This prevents a security vulnerability [documented by JitBit](https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/).
 
 When using `gl-link`, using `target="_blank"` is sufficient as it automatically adds `rel="noopener noreferrer"` to the link.
 

doc/development/fe_guide/style/scss.md

@@ -51,7 +51,7 @@ We recommend a "utility-first" approach.
 1. Start with utility classes.
 1. If composing utility classes into a component class removes code duplication and encapsulates a clear responsibility, do it.
 
-This encourages an organic growth of component classes and prevents the creation of one-off non-reusable classes. Also, the kind of classes that emerge from "utility-first" tend to be design-centered (e.g. `.button`, `.alert`, `.card`) rather than domain-centered (e.g. `.security-report-widget`, `.commit-header-icon`).
+This encourages an organic growth of component classes and prevents the creation of one-off non-reusable classes. Also, the kind of classes that emerge from "utility-first" tend to be design-centered (for example, `.button`, `.alert`, `.card`) rather than domain-centered (for example, `.security-report-widget`, `.commit-header-icon`).
 
 Inspiration:
 

doc/development/feature_flags/controls.md

@@ -221,7 +221,7 @@ you should fully roll out the feature by enabling the flag **globally** by runni
 ```
 
 This changes the feature flag state to be **enabled** always, which overrides the
-existing gates (e.g. `--group=gitlab-org`) in the above processes.
+existing gates (for example, `--group=gitlab-org`) in the above processes.
 
 Note, that if an actor based feature gate is present, switching the
 `default_enabled` attribute of the YAML definition from `false` to `true`

doc/development/feature_flags/index.md

@@ -61,7 +61,7 @@ When the feature implementation is delivered among multiple merge requests:
 One might be tempted to think that feature flags will delay the release of a
 feature by at least one month (= one release). This is not the case. A feature
 flag does not have to stick around for a specific amount of time
-(e.g. at least one release), instead they should stick around until the feature
+(for example, at least one release), instead they should stick around until the feature
 is deemed stable. Stable means it works on GitLab.com without causing any
 problems, such as outages.
 

doc/development/foreign_keys.md

@@ -17,7 +17,7 @@ end
 
 Here you will need to add a foreign key on column `posts.user_id`. This ensures
 that data consistency is enforced on database level. Foreign keys also mean that
-the database can very quickly remove associated data (e.g. when removing a
+the database can very quickly remove associated data (for example, when removing a
 user), instead of Rails having to do this.
 
 ## Adding Foreign Keys In Migrations

doc/development/geo.md

@@ -56,7 +56,7 @@ Geo uses [streaming replication](#streaming-replication) to replicate
 the database from the **primary** to the **secondary** nodes. This
 replication gives the **secondary** nodes access to all the data saved
 in the database. So users can log in on the **secondary** and read all
-the issues, merge requests, etc. on the **secondary** node.
+the issues, merge requests, and so on, on the **secondary** node.
 
 ### Repository replication
 
@@ -127,7 +127,7 @@ periodically to sync all uploads that aren't synced to the Geo
 
 Files are copied via HTTP(s) and initiated via the
 `/api/v4/geo/transfers/:type/:id` endpoint,
-e.g. `/api/v4/geo/transfers/lfs/123`.
+for example, `/api/v4/geo/transfers/lfs/123`.
 
 ## Authentication
 
@@ -219,7 +219,7 @@ bundle exec rake geo:db:migrate
 
 Geo uses [Finders](https://gitlab.com/gitlab-org/gitlab/-/tree/master/app/finders),
 which are classes take care of the heavy lifting of looking up
-projects/attachments/etc. in the tracking database and main database.
+projects/attachments/ and so on, in the tracking database and main database.
 
 ## Redis
 
@@ -228,7 +228,7 @@ node. It is used for caching, storing sessions, and other persistent
 data.
 
 Redis data replication between **primary** and **secondary** node is
-not used, so sessions etc. aren't shared between nodes.
+not used, so sessions and so on, aren't shared between nodes.
 
 ## Object Storage
 

doc/development/git_object_deduplication.md

@@ -163,7 +163,7 @@ repository and a pool.
 
 ### Pool existence
 
-If GitLab thinks a pool repository exists (i.e. it exists according to
+If GitLab thinks a pool repository exists (that is, it exists according to
 SQL), but it does not on the Gitaly server, then it is created on
 the fly by Gitaly.
 

doc/development/github_importer.md

@@ -145,7 +145,7 @@ long we're still performing work.
 
 GitHub has a rate limit of 5,000 API calls per hour. The number of requests
 necessary to import a project is largely dominated by the number of unique users
-involved in a project (e.g. issue authors). Other data such as issue pages
+involved in a project (for example, issue authors). Other data such as issue pages
 and comments typically only requires a few dozen requests to import. This is
 because we need the Email address of users in order to map them to GitLab users.
 

doc/development/go_guide/index.md

@@ -14,7 +14,7 @@ projects using the [Go language](https://golang.org).
 GitLab is built on top of [Ruby on Rails](https://rubyonrails.org/), but we're
 also using Go for projects where it makes sense. Go is a very powerful
 language, with many advantages, and is best suited for projects with a lot of
-IO (disk/network access), HTTP requests, parallel processing, etc. Since we
+IO (disk/network access), HTTP requests, parallel processing, and so on. Since we
 have both Ruby on Rails and Go at GitLab, we should evaluate carefully which of
 the two is best for the job.
 
@@ -390,7 +390,7 @@ consistent across Workhorse, Gitaly, and, in future, other Go servers. For
 example, in the case of `gitlab.com/gitlab-org/labkit/tracing` we can switch
 from using `Opentracing` directly to using `Zipkin` or Gokit's own tracing wrapper
 without changes to the application code, while still keeping the same
-consistent configuration mechanism (i.e. the `GITLAB_TRACING` environment
+consistent configuration mechanism (that is, the `GITLAB_TRACING` environment
 variable).
 
 ### Context
@@ -437,7 +437,7 @@ and the version being used for [CNG](https://gitlab.com/gitlab-org/build/cng/blo
 ### Updating Go version
 
 We should always use a [supported version](https://golang.org/doc/devel/release#policy)
-of Go, i.e., one of the three most recent minor releases, and should always use
+of Go, that is, one of the three most recent minor releases, and should always use
 the most recent patch-level for that version, as it may contain security fixes.
 
 Changing the version affects every project being compiled, so it's important to

doc/development/logging.md

@@ -58,12 +58,12 @@ Structured logging solves these problems. Consider the example from an API reque
 
 In a single line, we've included all the information that a user needs
 to understand what happened: the timestamp, HTTP method and path, user
-ID, etc.
+ID, and so on.
 
 ### How to use JSON logging
 
 Suppose you want to log the events that happen in a project
-importer. You want to log issues created, merge requests, etc. as the
+importer. You want to log issues created, merge requests, and so on, as the
 importer progresses. Here's what to do:
 
 1. Look at [the list of GitLab Logs](../administration/logs.md) to see
@@ -174,7 +174,7 @@ Resources:
 
 Similar to timezones, choosing the right time unit to log can impose avoidable overhead. So, whenever
 challenged to choose between seconds, milliseconds or any other unit, lean towards _seconds_ as float
-(with microseconds precision, i.e. `Gitlab::InstrumentationHelper::DURATION_PRECISION`).
+(with microseconds precision, that is, `Gitlab::InstrumentationHelper::DURATION_PRECISION`).
 
 In order to make it easier to track timings in the logs, make sure the log key has `_s` as
 suffix and `duration` within its name (for example, `view_duration_s`).

doc/development/merge_request_performance_guidelines.md

@@ -179,9 +179,9 @@ As a counterpart of the `without_sticky_writes` utility,
 replicas regardless of the current primary stickiness.
 This utility is reserved for cases where queries can tolerate replication lag.
 
-Internally, our database load balancer classifies the queries based on their main statement (`select`, `update`, `delete`, etc.). When in doubt, it redirects the queries to the primary database. Hence, there are some common cases the load balancer sends the queries to the primary unnecessarily:
+Internally, our database load balancer classifies the queries based on their main statement (`select`, `update`, `delete`, and so on). When in doubt, it redirects the queries to the primary database. Hence, there are some common cases the load balancer sends the queries to the primary unnecessarily:
 
-- Custom queries (via `exec_query`, `execute_statement`, `execute`, etc.)
+- Custom queries (via `exec_query`, `execute_statement`, `execute`, and so on)
 - Read-only transactions
 - In-flight connection configuration set
 - Sidekiq background jobs
@@ -567,7 +567,7 @@ to work with you to possibly discover a better solution.
 The usage of local storage is a desired solution to use,
 especially since we work on deploying applications to Kubernetes clusters.
 When you would like to use `Dir.mktmpdir`? In a case when you want for example
-to extract/create archives, perform extensive manipulation of existing data, etc.
+to extract/create archives, perform extensive manipulation of existing data, and so on.
 
 ```ruby
 Dir.mktmpdir('designs') do |path|

doc/development/migration_style_guide.md

@@ -605,7 +605,7 @@ perform existence checks internally.
 When adding a foreign-key constraint to either an existing or a new column also
 remember to add an index on the column.
 
-This is **required** for all foreign-keys, e.g., to support efficient cascading
+This is **required** for all foreign-keys, for example, to support efficient cascading
 deleting: when a lot of rows in a table get deleted, the referenced records need
 to be deleted too. The database has to look for corresponding records in the
 referenced table. Without an index, this results in a sequential scan on the

doc/development/module_with_instance_variables.md

@@ -49,9 +49,9 @@ instance variables in the final giant object, and that's where the problem is.
 ## Solutions
 
 We should split the giant object into multiple objects, and they communicate
-with each other with the API, i.e. public methods. In short, composition over
+with each other with the API, that is, public methods. In short, composition over
 inheritance. This way, each smaller objects would have their own respective
-limited states, i.e. instance variables. If one instance variable goes wrong,
+limited states, that is, instance variables. If one instance variable goes wrong,
 we would be very clear that it's from that single small object, because
 no one else could be touching it.
 

doc/development/multi_version_compatibility.md

@@ -304,7 +304,7 @@ variable `CI_NODE_TOTAL` being an integer failed. This was caused because after
 1. As a result, the [new code](https://gitlab.com/gitlab-org/gitlab/-/blob/42b82a9a3ac5a96f9152aad6cbc583c42b9fb082/app/models/concerns/ci/contextable.rb#L104)
 was not run on the API server. The runner's request failed because the
 older API server tried return the `CI_NODE_TOTAL` CI/CD variable, but
-instead of sending an integer value (e.g. 9), it sent a serialized
+instead of sending an integer value (for example, 9), it sent a serialized
 `Hash` value (`{:number=>9, :total=>9}`).
 
 If you look at the [deployment pipeline](https://ops.gitlab.net/gitlab-com/gl-infra/deployer/-/pipelines/202212),

doc/development/omnibus.md

@@ -12,7 +12,7 @@ when you are coding.
 
 ## Files are owned by root by default
 
-All the files in the Rails tree (`app/`, `config/` etc.) are owned by `root` in
+All the files in the Rails tree (`app/`, `config/`, and so on) are owned by `root` in
 Omnibus installations. This makes the installation simpler and it provides
 extra security. The Omnibus reconfigure script contains commands that give
 write access to the `git` user only where needed.

doc/development/packages.md

@@ -191,7 +191,7 @@ against the project or group before continuing.
 The current database model allows you to store a name and a version for each package.
 Every time you upload a new package, you can either create a new record of `Package`
 or add files to existing record. `PackageFile` should be able to store all file-related
-information like the file `name`, `side`, `sha1`, etc.
+information like the file `name`, `side`, `sha1`, and so on.
 
 If there is specific data necessary to be stored for only one package system support,
 consider creating a separate metadata model. See `packages_maven_metadata` table

doc/development/performance.md

@@ -120,7 +120,7 @@ allowing you to profile which code is running on CPU in detail.
 It's important to note that profiling an application *alters its performance*.
 Different profiling strategies have different overheads. Stackprof is a sampling
 profiler. It samples stack traces from running threads at a configurable
-frequency (e.g. 100hz, that is 100 stacks per second). This type of profiling
+frequency (for example, 100hz, that is 100 stacks per second). This type of profiling
 has quite a low (albeit non-zero) overhead and is generally considered to be
 safe for production.
 

doc/development/pipelines.md

@@ -51,7 +51,7 @@ depending on the changes made in the MR:
 
 We use the [`rules:`](../ci/yaml/index.md#rules) and [`needs:`](../ci/yaml/index.md#needs) keywords extensively
 to determine the jobs that need to be run in a pipeline. Note that an MR that includes multiple types of changes would
-have a pipelines that include jobs from multiple types (e.g. a combination of docs-only and code-only pipelines).
+have a pipelines that include jobs from multiple types (for example, a combination of docs-only and code-only pipelines).
 
 #### Documentation only MR pipeline
 
@@ -557,7 +557,7 @@ request, be sure to start the `dont-interrupt-me` job before pushing.
    - `.yarn-cache`
    - `.assets-compile-cache` (the key includes `${NODE_ENV}` so it's actually two different caches).
 1. These cache definitions are composed of [multiple atomic caches](../ci/caching/index.md#use-multiple-caches).
-1. Only the following jobs, running in 2-hourly scheduled pipelines, are pushing (i.e. updating) to the caches:
+1. Only the following jobs, running in 2-hourly scheduled pipelines, are pushing (that is, updating) to the caches:
    - `update-setup-test-env-cache`, defined in [`.gitlab/ci/rails.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/rails.gitlab-ci.yml).
    - `update-gitaly-binaries-cache`, defined in [`.gitlab/ci/rails.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/rails.gitlab-ci.yml).
    - `update-static-analysis-cache`, defined in [`.gitlab/ci/rails.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/rails.gitlab-ci.yml).
@@ -653,7 +653,7 @@ The current stages are:
 - `fixtures`: This stage includes jobs that prepare fixtures needed by frontend tests.
 - `test`: This stage includes most of the tests, DB/migration jobs, and static analysis jobs.
 - `post-test`: This stage includes jobs that build reports or gather data from
-  the `test` stage's jobs (e.g. coverage, Knapsack metadata etc.).
+  the `test` stage's jobs (for example, coverage, Knapsack metadata, and so on).
 - `review-prepare`: This stage includes a job that build the CNG images that are
   later used by the (Helm) Review App deployment (see
   [Review Apps](testing_guide/review_apps.md) for details).
@@ -663,9 +663,9 @@ that is deployed in stage `review`.
 - `qa`: This stage includes jobs that perform QA tasks against the Review App
   that is deployed in stage `review`.
 - `post-qa`: This stage includes jobs that build reports or gather data from
-  the `qa` stage's jobs (e.g. Review App performance report).
+  the `qa` stage's jobs (for example, Review App performance report).
 - `pages`: This stage includes a job that deploys the various reports as
-  GitLab Pages (e.g. [`coverage-ruby`](https://gitlab-org.gitlab.io/gitlab/coverage-ruby/),
+  GitLab Pages (for example, [`coverage-ruby`](https://gitlab-org.gitlab.io/gitlab/coverage-ruby/),
   [`coverage-javascript`](https://gitlab-org.gitlab.io/gitlab/coverage-javascript/),
   and `webpack-report` (found at `https://gitlab-org.gitlab.io/gitlab/webpack-report/`, but there is
   [an issue with the deployment](https://gitlab.com/gitlab-org/gitlab/-/issues/233458)).
@@ -721,7 +721,7 @@ that are scoped to a single [configuration keyword](../ci/yaml/index.md#job-keyw
 | Job definitions  | Description |
 |------------------|-------------|
 | `.default-retry` | Allows a job to [retry](../ci/yaml/index.md#retry) upon `unknown_failure`, `api_failure`, `runner_system_failure`, `job_execution_timeout`, or `stuck_or_timeout_failure`. |
-| `.default-before_script` | Allows a job to use a default `before_script` definition suitable for Ruby/Rails tasks that may need a database running (e.g. tests). |
+| `.default-before_script` | Allows a job to use a default `before_script` definition suitable for Ruby/Rails tasks that may need a database running (for example, tests). |
 | `.setup-test-env-cache` | Allows a job to use a default `cache` definition suitable for setting up test environment for subsequent Ruby/Rails tasks. |
 | `.rails-cache` | Allows a job to use a default `cache` definition suitable for Ruby/Rails tasks. |
 | `.static-analysis-cache` | Allows a job to use a default `cache` definition suitable for static analysis tasks. |
@@ -757,8 +757,8 @@ and included in `rules` definitions via [YAML anchors](../ci/yaml/index.md#ancho
 | `if:` conditions | Description | Notes |
 |------------------|-------------|-------|
 | `if-not-canonical-namespace`                                 | Matches if the project isn't in the canonical (`gitlab-org/`) or security (`gitlab-org/security`) namespace. | Use to create a job for forks (by using `when: on_success|manual`), or **not** create a job for forks (by using `when: never`). |
-| `if-not-ee`                                                  | Matches if the project isn't EE (i.e. project name isn't `gitlab` or `gitlab-ee`). | Use to create a job only in the FOSS project (by using `when: on_success|manual`), or **not** create a job if the project is EE (by using `when: never`). |
-| `if-not-foss`                                                | Matches if the project isn't FOSS (i.e. project name isn't `gitlab-foss`, `gitlab-ce`, or `gitlabhq`). | Use to create a job only in the EE project (by using `when: on_success|manual`), or **not** create a job if the project is FOSS (by using `when: never`). |
+| `if-not-ee`                                                  | Matches if the project isn't EE (that is, project name isn't `gitlab` or `gitlab-ee`). | Use to create a job only in the FOSS project (by using `when: on_success|manual`), or **not** create a job if the project is EE (by using `when: never`). |
+| `if-not-foss`                                                | Matches if the project isn't FOSS (that is, project name isn't `gitlab-foss`, `gitlab-ce`, or `gitlabhq`). | Use to create a job only in the EE project (by using `when: on_success|manual`), or **not** create a job if the project is FOSS (by using `when: never`). |
 | `if-default-refs`                                            | Matches if the pipeline is for `master`, `main`, `/^[\d-]+-stable(-ee)?$/` (stable branches), `/^\d+-\d+-auto-deploy-\d+$/` (auto-deploy branches), `/^security\//` (security branches), merge requests, and tags. | Note that jobs aren't created for branches with this default configuration. |
 | `if-master-refs`                                             | Matches if the current branch is `master` or `main`. | |
 | `if-master-push`                                             | Matches if the current branch is `master` or `main` and pipeline source is `push`. | |
@@ -797,11 +797,11 @@ and included in `rules` definitions via [YAML anchors](../ci/yaml/index.md#ancho
 | `ci-qa-patterns`             | Only create job for CI configuration-related changes related to the `qa` stage. |
 | `yaml-lint-patterns`         | Only create job for YAML-related changes.                                |
 | `docs-patterns`              | Only create job for docs-related changes.                                |
-| `frontend-dependency-patterns` | Only create job when frontend dependencies are updated (i.e. `package.json`, and `yarn.lock`). changes. |
+| `frontend-dependency-patterns` | Only create job when frontend dependencies are updated (that is, `package.json`, and `yarn.lock`). changes. |
 | `frontend-patterns`          | Only create job for frontend-related changes.                           |
 | `backend-patterns`           | Only create job for backend-related changes.                           |
 | `db-patterns`                | Only create job for DB-related changes. |
-| `backstage-patterns`         | Only create job for backstage-related changes (i.e. Danger, fixtures, RuboCop, specs). |
+| `backstage-patterns`         | Only create job for backstage-related changes (that is, Danger, fixtures, RuboCop, specs). |
 | `code-patterns`              | Only create job for code-related changes.                                |
 | `qa-patterns`                | Only create job for QA-related changes.                                  |
 | `code-backstage-patterns`    | Combination of `code-patterns` and `backstage-patterns`.                 |

doc/development/policies.md

@@ -106,7 +106,7 @@ Each line represents a rule that was evaluated. There are a few things to note:
 1. The `-` or `+` symbol indicates whether the rule block was evaluated to be
    `false` or `true`, respectively.
 1. The number inside the brackets indicates the score.
-1. The last part of the line (e.g. `@john : Issue/1`) shows the username
+1. The last part of the line (for example, `@john : Issue/1`) shows the username
    and subject for that rule.
 
 Here you can see that the first four rules were evaluated `false` for
@@ -150,7 +150,7 @@ then the result of the condition is cached globally only based on the subject -
 **DANGER**: If you use a `:scope` option when the condition actually uses data from
 both user and subject (including a simple anonymous check!) your result is cached at too global of a scope and results in cache bugs.
 
-Sometimes we are checking permissions for a lot of users for one subject, or a lot of subjects for one user. In this case, we want to set a *preferred scope* - i.e. tell the system that we prefer rules that can be cached on the repeated parameter. For example, in `Ability.users_that_can_read_project`:
+Sometimes we are checking permissions for a lot of users for one subject, or a lot of subjects for one user. In this case, we want to set a *preferred scope* - that is, tell the system that we prefer rules that can be cached on the repeated parameter. For example, in `Ability.users_that_can_read_project`:
 
 ```ruby
 def users_that_can_read_project(users, project)

doc/development/polymorphic_associations.md

@@ -146,7 +146,7 @@ filter rows using the `IS NULL` condition.
 
 To summarize: using separate tables allows us to use foreign keys effectively,
 create indexes only where necessary, conserve space, query data more
-efficiently, and scale these tables more easily (e.g. by storing them on
+efficiently, and scale these tables more easily (for example, by storing them on
 separate disks). A nice side effect of this is that code can also become easier,
 as a single model isn't responsible for handling different kinds of
 data.

doc/development/pry_debugging.md

@@ -129,7 +129,7 @@ end
 ## Repeat last command
 
 You can repeat the last command by just hitting the <kbd>Enter</kbd>
-key (e.g., with `step` or`next`), if you place the following snippet
+key (for example, with `step` or`next`), if you place the following snippet
 in your `~/.pryrc`:
 
 ```ruby

doc/development/query_recorder.md

@@ -48,7 +48,7 @@ end
 Use a [request spec](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/spec/requests) when writing a N+1 test on the controller level.
 
 Controller specs should not be used to write N+1 tests as the controller is only initialized once per example.
-This could lead to false successes where subsequent "requests" could have queries reduced (e.g. because of memoization).
+This could lead to false successes where subsequent "requests" could have queries reduced (for example, because of memoization).
 
 ## Finding the source of the query
 

doc/development/rails_initializers.md

@@ -19,4 +19,4 @@ Ruby files in this folder are loaded in alphabetical order just like the default
 Some examples where you would need to do this are:
 
 1. Modifying Rails' `config.autoload_paths`
-1. Changing configuration that Zeitwerk uses, e.g. inflections
+1. Changing configuration that Zeitwerk uses, for example, inflections

doc/development/reactive_caching.md

@@ -258,7 +258,7 @@ self.reactive_cache_hard_limit = 5.megabytes
 - This is the type of work performed by the `calculate_reactive_cache` method. Based on this attribute,
 it's able to pick the right worker to process the caching job. Make sure to
 set it as `:external_dependency` if the work performs any external request
-(e.g. Kubernetes, Sentry); otherwise set it to `:no_dependency`.
+(for example, Kubernetes, Sentry); otherwise set it to `:no_dependency`.
 
 #### `self.reactive_cache_worker_finder`
 

doc/development/refactoring_guide/index.md

@@ -14,7 +14,7 @@ Pinning tests help you ensure that you don't unintentionally change the output o
 
 ### Example steps
 
-1. Identify all the possible inputs to the refactor subject (e.g. anything that's injected into the template or used in a conditional).
+1. Identify all the possible inputs to the refactor subject (for example, anything that's injected into the template or used in a conditional).
 1. For each possible input, identify the significant possible values.
 1. Create a test to save a full detailed snapshot for each helpful combination values per input. This should guarantee that we have "pinned down" the current behavior. The snapshot could be literally a screenshot, a dump of HTML, or even an ordered list of debugging statements.
 1. Run all the pinning tests against the code, before you start refactoring (Oracle)

doc/development/renaming_features.md

@@ -12,7 +12,7 @@ Sometimes the business asks to change the name of a feature. Broadly speaking, t
   - Pros: does not increase code complexity.
   - Cons: more work to execute, and higher risk of immediate bugs.
 - Façade, rename as little as possible; only the user-facing content like interfaces,
-  documentation, error messages, etc.
+  documentation, error messages, and so on.
   - Pros: less work to execute.
   - Cons: increases code complexity, creating higher risk of future bugs.
 

doc/development/reusing_abstractions.md

@@ -215,7 +215,7 @@ provided by Active Record are not included, except for the following methods:
 ### Active Record
 
 The API provided by Active Record itself, such as the `where` method, `save`,
-`delete_all`, etc.
+`delete_all`, and so on.
 
 ### Worker
 

doc/development/scalability.md

@@ -23,7 +23,7 @@ users. We discuss each component below.
 ### PostgreSQL
 
 The PostgreSQL database holds all metadata for projects, issues, merge
-requests, users, etc. The schema is managed by the Rails application
+requests, users, and so on. The schema is managed by the Rails application
 [db/structure.sql](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/structure.sql).
 
 GitLab Web/API servers and Sidekiq nodes talk directly to the database by using a
@@ -91,7 +91,7 @@ ownership. It shares a lot of challenges with traditional, data-oriented
 sharding, however. For instance, joining data has to happen in the
 application itself rather than on the query layer (although additional
 layers like GraphQL might mitigate that) and it requires true
-parallelism to run efficiently (i.e. a scatter-gather model to collect,
+parallelism to run efficiently (that is, a scatter-gather model to collect,
 then zip up data records), which is a challenge in itself in Ruby based
 systems.
 

doc/development/secure_coding_guidelines.md

@@ -49,7 +49,7 @@ Each time you implement a new feature/endpoint, whether it is at UI, API or Grap
 - Do not forget **abuse cases**: write specs that **make sure certain things can't happen**
   - A lot of specs are making sure things do happen and coverage percentage doesn't take into account permissions as same piece of code is used.
   - Make assertions that certain actors cannot perform actions
-- Naming convention to ease auditability: to be defined, e.g. a subfolder containing those specific permission tests or a `#permissions` block
+- Naming convention to ease auditability: to be defined, for example, a subfolder containing those specific permission tests or a `#permissions` block
 
 Be careful to **also test [visibility levels](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/doc/development/permissions.md#feature-specific-permissions)** and not only project access rights.
 
@@ -59,13 +59,13 @@ Some example of well implemented access controls and tests:
 1. [example2](https://dev.gitlab.org/gitlab/gitlabhq/-/merge_requests/2511/diffs#ed3aaab1510f43b032ce345909a887e5b167e196_142_155)
 1. [example3](https://dev.gitlab.org/gitlab/gitlabhq/-/merge_requests/3170/diffs?diff_id=17494)
 
-**NB:** any input from development team is welcome, e.g. about Rubocop rules.
+**NB:** any input from development team is welcome, for example, about Rubocop rules.
 
 ## Regular Expressions guidelines
 
 ### Anchors / Multi line
 
-Unlike other programming languages (e.g. Perl or Python) Regular Expressions are matching multi-line by default in Ruby. Consider the following example in Python:
+Unlike other programming languages (for example, Perl or Python) Regular Expressions are matching multi-line by default in Ruby. Consider the following example in Python:
 
 ```python
 import re

doc/development/serializing_data.md

@@ -35,7 +35,7 @@ turn there's no way to query the data at all.
 ## Waste Of Space
 
 Storing serialized data such as JSON or YAML will end up wasting a lot of space.
-This is because these formats often include additional characters (e.g. double
+This is because these formats often include additional characters (for example, double
 quotes or newlines) besides the data that you are storing.
 
 ## Difficult To Manage
@@ -69,9 +69,9 @@ can easily take hours or even days to complete.
 ## Relational Databases Are Not Document Stores
 
 When storing data as JSON or YAML you're essentially using your database as if
-it were a document store (e.g. MongoDB), except you're not using any of the
+it were a document store (for example, MongoDB), except you're not using any of the
 powerful features provided by a typical RDBMS _nor_ are you using any of the
-features provided by a typical document store (e.g. the ability to index fields
+features provided by a typical document store (for example, the ability to index fields
 of documents with variable fields). In other words, it's a waste.
 
 ## Consistent Fields