From e38b9bccc6533aa5511c84178a990a569570c60c Mon Sep 17 00:00:00 2001
From: Jonston Chan <jonstonchan1@gmail.com>
Date: Fri, 13 May 2022 04:42:38 +0000
Subject: [PATCH] Remove (s) as suggested by style guide
---
doc/ci/services/index.md | 2 +-
doc/development/adding_database_indexes.md | 4 ++--
doc/development/code_intelligence/index.md | 2 +-
doc/development/code_review.md | 8 ++++----
doc/development/contributing/design.md | 4 ++--
doc/development/contributing/merge_request_workflow.md | 4 ++--
.../database/avoiding_downtime_in_migrations.md | 2 +-
doc/development/database/loose_foreign_keys.md | 4 ++--
doc/development/database/table_partitioning.md | 2 +-
doc/development/fe_guide/graphql.md | 2 +-
10 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/doc/ci/services/index.md b/doc/ci/services/index.md
index e6406818b4c75..e876c6d7326c9 100644
--- a/doc/ci/services/index.md
+++ b/doc/ci/services/index.md
@@ -80,7 +80,7 @@ As mentioned before, this feature is designed to provide **network accessible**
services. A database is the simplest example of such a service.
The services feature is not designed to, and does not, add any software from the
-defined `services` image(s) to the job's container.
+defined `services` images to the job's container.
For example, if you have the following `services` defined in your job, the `php`,
`node` or `go` commands are **not** available for your script, and the job fails:
diff --git a/doc/development/adding_database_indexes.md b/doc/development/adding_database_indexes.md
index d263d9b5eb5b1..a23ab7d068988 100644
--- a/doc/development/adding_database_indexes.md
+++ b/doc/development/adding_database_indexes.md
@@ -158,7 +158,7 @@ and should not be used. Some other points to consider:
### Why explicit names are required
As Rails is database agnostic, it generates an index name only
-from the required options of all indexes: table name and column name(s).
+from the required options of all indexes: table name and column names.
For example, imagine the following two indexes are created in a migration:
```ruby
@@ -173,7 +173,7 @@ Creation of the second index would fail, because Rails would generate
the same name for both indexes.
This is further complicated by the behavior of the `index_exists?` method.
-It considers only the table name, column name(s) and uniqueness specification
+It considers only the table name, column names, and uniqueness specification
of the index when making a comparison. Consider:
```ruby
diff --git a/doc/development/code_intelligence/index.md b/doc/development/code_intelligence/index.md
index e1e2105298c16..3a8845084c3d3 100644
--- a/doc/development/code_intelligence/index.md
+++ b/doc/development/code_intelligence/index.md
@@ -38,7 +38,7 @@ sequenceDiagram
1. The CI/CD job generates a document in an LSIF format (usually `dump.lsif`) using [an
indexer](https://lsif.dev) for the language of a project. The format
[describes](https://github.com/sourcegraph/sourcegraph/blob/main/doc/code_intelligence/explanations/writing_an_indexer.md)
- interactions between a method or function and its definition(s) or references. The
+ interactions between a method or function and its definitions or references. The
document is marked to be stored as an LSIF report artifact.
1. After receiving a request for storing the artifact, Workhorse asks
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index a296717151e87..2b1b23bd09704 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -26,7 +26,7 @@ This is only a recommendation and the reviewer may be from a different team.
However, it is recommended to pick someone who is a [domain expert](#domain-experts).
If your merge request touches more than one domain (for example, Dynamic Analysis and GraphQL), ask for reviews from an expert from each domain.
-You can read more about the importance of involving reviewer(s) in the section on the responsibility of the author below.
+You can read more about the importance of involving reviewers in the section on the responsibility of the author below.
If you need some guidance (for example, it's your first merge request), feel free to ask
one of the [Merge request coaches](https://about.gitlab.com/company/team/).
@@ -107,7 +107,7 @@ For more information, review [the roulette README](https://gitlab.com/gitlab-org
### Approval guidelines
As described in the section on the responsibility of the maintainer below, you
-are recommended to get your merge request approved and merged by maintainer(s)
+are recommended to get your merge request approved and merged by maintainers
with [domain expertise](#domain-experts).
1. If your merge request includes backend changes (*1*), it must be
@@ -440,7 +440,7 @@ experience, refactors the existing code). Then:
- For non-mandatory suggestions, decorate with (non-blocking) so the author knows they can
optionally resolve within the merge request or follow-up at a later stage.
- There's a [Chrome/Firefox add-on](https://gitlab.com/conventionalcomments/conventional-comments-button) which you can use to apply [Conventional Comment](https://conventionalcomments.org/) prefixes.
-- Ensure there are no open dependencies. Check [linked issues](../user/project/issues/related_issues.md) for blockers. Clarify with the author(s)
+- Ensure there are no open dependencies. Check [linked issues](../user/project/issues/related_issues.md) for blockers. Clarify with the authors
if necessary. If blocked by one or more open MRs, set an [MR dependency](../user/project/merge_requests/merge_request_dependencies.md).
- After a round of line notes, it can be helpful to post a summary note such as
"Looks good to me", or "Just a couple things to address."
@@ -693,7 +693,7 @@ Properties of customer critical merge requests:
- The [VP of Development](https://about.gitlab.com/job-families/engineering/development/management/vp/) ([@clefelhocz1](https://gitlab.com/clefelhocz1)) is the DRI for deciding if a merge request qualifies as customer critical.
- The DRI applies the `customer-critical-merge-request` label to the merge request.
-- It is required that the reviewer(s) and maintainer(s) involved with a customer critical merge request are engaged as soon as this decision is made.
+- It is required that the reviewers and maintainers involved with a customer critical merge request are engaged as soon as this decision is made.
- It is required to prioritize work for those involved on a customer critical merge request so that they have the time available necessary to focus on it.
- It is required to adhere to GitLab [values](https://about.gitlab.com/handbook/values/) and processes when working on customer critical merge requests, taking particular note of family and friends first/work second, definition of done, iteration, and release when it's ready.
- Customer critical merge requests are required to not reduce security, introduce data-loss risk, reduce availability, nor break existing functionality per the process for [prioritizing technical decisions](https://about.gitlab.com/handbook/engineering/development/principles/#prioritizing-technical-decisions).
diff --git a/doc/development/contributing/design.md b/doc/development/contributing/design.md
index def39a960d85b..a3428972f8799 100644
--- a/doc/development/contributing/design.md
+++ b/doc/development/contributing/design.md
@@ -117,7 +117,7 @@ At any moment, but usually _during_ or _after_ the design's implementation:
for additions or enhancements to the design system.
- Create issues with the [`~UX debt`](issue_workflow.md#technical-and-ux-debt)
label for intentional deviations from the agreed-upon UX requirements due to
- time or feasibility challenges, linking back to the corresponding issue(s) or
- MR(s).
+ time or feasibility challenges, linking back to the corresponding issues or
+ MRs.
- Create issues for [feature additions or enhancements](issue_workflow.md#feature-proposals)
outside the agreed-upon UX requirements to avoid scope creep.
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index 5ed0885eed99c..5fdeb653256d8 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -53,7 +53,7 @@ request is as follows:
1. If you have multiple commits, combine them into a few logically organized
commits by [squashing them](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing),
but do not change the commit history if you're working on shared branches though.
-1. Push the commit(s) to your working branch in your fork.
+1. Push the commits to your working branch in your fork.
1. Submit a merge request (MR) to the `main` branch in the main GitLab project.
1. Your merge request needs at least 1 approval, but depending on your changes
you might need additional approvals. Refer to the [Approval guidelines](../code_review.md#approval-guidelines).
@@ -65,7 +65,7 @@ request is as follows:
template already provided in the "Description" field.
1. If you are contributing documentation, choose `Documentation` from the
"Choose a template" menu and fill in the description according to the template.
- 1. Use the syntax `Solves #XXX`, `Closes #XXX`, or `Refs #XXX` to mention the issue(s) your merge
+ 1. Use the syntax `Solves #XXX`, `Closes #XXX`, or `Refs #XXX` to mention the issues your merge
request addresses. Referenced issues do not [close automatically](../../user/project/issues/managing_issues.md#closing-issues-automatically).
You must close them manually once the merge request is merged.
1. The MR must include *Before* and *After* screenshots if UI changes are made.
diff --git a/doc/development/database/avoiding_downtime_in_migrations.md b/doc/development/database/avoiding_downtime_in_migrations.md
index a849095d61a82..3cf9ab1ab5c10 100644
--- a/doc/development/database/avoiding_downtime_in_migrations.md
+++ b/doc/development/database/avoiding_downtime_in_migrations.md
@@ -334,7 +334,7 @@ Renaming a table is possible without downtime by following our multi-release
Adding foreign keys usually works in 3 steps:
1. Start a transaction
-1. Run `ALTER TABLE` to add the constraint(s)
+1. Run `ALTER TABLE` to add the constraints
1. Check all existing data
Because `ALTER TABLE` typically acquires an exclusive lock until the end of a
diff --git a/doc/development/database/loose_foreign_keys.md b/doc/development/database/loose_foreign_keys.md
index 2bcdc91202af9..61984d2e12a65 100644
--- a/doc/development/database/loose_foreign_keys.md
+++ b/doc/development/database/loose_foreign_keys.md
@@ -117,8 +117,8 @@ Showing cross-schema foreign keys (20):
18 | N | ci_job_token_project_scope_links | projects | target_project_id | cascade
19 | N | ci_project_monthly_usages | projects | project_id | cascade
-To match FK write one or many filters to match against FROM/TO/COLUMN:
-- scripts/decomposition/generate-loose-foreign-key <filter(s)...>
+To match foreign key (FK), write one or many filters to match against FROM/TO/COLUMN:
+- scripts/decomposition/generate-loose-foreign-key <filters...>
- scripts/decomposition/generate-loose-foreign-key ci_job_artifacts project_id
- scripts/decomposition/generate-loose-foreign-key dast_site_profiles_pipelines
```
diff --git a/doc/development/database/table_partitioning.md b/doc/development/database/table_partitioning.md
index ec76813640421..34cb73978bc32 100644
--- a/doc/development/database/table_partitioning.md
+++ b/doc/development/database/table_partitioning.md
@@ -43,7 +43,7 @@ problem.
First, a table is partitioned on a partition key, which is a column or
set of columns which determine how the data will be split across the
partitions. The partition key is used by the database when reading or
-writing data, to decide which partition(s) need to be accessed. The
+writing data, to decide which partitions need to be accessed. The
partition key should be a column that would be included in a `WHERE`
clause on almost all queries accessing that table.
diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md
index 9cd0cc969b5fa..5cfdaff04482b 100644
--- a/doc/development/fe_guide/graphql.md
+++ b/doc/development/fe_guide/graphql.md
@@ -1987,7 +1987,7 @@ To improve performance, sometimes we want to make initial GraphQL queries early.
}
```
-- Add startup call(s) with correct variables to the HAML file that serves as a view
+- Add startup calls with correct variables to the HAML file that serves as a view
for your application. To add GraphQL startup calls, we use
`add_page_startup_graphql_call` helper where the first parameter is a path to the
query, the second one is an object containing query variables. Path to the query is
--
GitLab