Add latest changes from gitlab-org/gitlab@master

4 files changed, 15 insertions, 15 deletions

diff --git a/doc/development/contributing/community_roles.md b/doc/development/contributing/community_roles.md
index 5419992517b..3804aa7f8a8 100644
--- a/doc/development/contributing/community_roles.md
+++ b/doc/development/contributing/community_roles.md
@@ -12,7 +12,7 @@ GitLab community members and their privileges/responsibilities.
 |-------|------------------|--------------|
 | Maintainer | Accepts merge requests on several GitLab projects | Added to the [team page](https://about.gitlab.com/company/team/). An expert on code reviews and knows the product/codebase |
 | Reviewer | Performs code reviews on MRs | Added to the [team page](https://about.gitlab.com/company/team/) |
-| Developer |Has access to GitLab internal infrastructure & issues (e.g. HR-related) | GitLab employee or a Core Team member (with an NDA) |
+| Developer |Has access to GitLab internal infrastructure & issues (for example, HR-related) | GitLab employee or a Core Team member (with an NDA) |
 | Contributor | Can make contributions to all GitLab public projects | Have a GitLab.com account |
 
 [List of current reviewers/maintainers](https://about.gitlab.com/handbook/engineering/projects/#gitlab-ce).
diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md
index 2fe08f78aed..fc9ed00d530 100644
--- a/doc/development/contributing/index.md
+++ b/doc/development/contributing/index.md
@@ -191,7 +191,7 @@ If you are not sure who to mention, the reviewer will do this for you early in t
 A "breaking change" is any change that requires users to make a corresponding change to their code, settings, or workflow. "Users" might be humans, API clients, or even code classes that "use" another class. Examples of breaking changes include:
 
 - Removing a user-facing feature without a replacement/workaround.
-- Changing the definition of an existing API (by re-naming query parameters, changing routes, etc.).
+- Changing the definition of an existing API (by doing things like re-naming query parameters or changing routes).
 - Removing a public method from a code class.
 
 A breaking change can be considered "major" if it affects many users, or represents a significant change in behavior.
diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index aa1b353c634..b1d18888afe 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -47,11 +47,11 @@ scheduling into milestones. Labeling is a task for everyone. (For some projects,
 
 Most issues will have labels for at least one of the following:
 
-- Type: `~feature`, `~bug`, `~tooling`, `~documentation`, etc.
-- Stage: `~"devops::plan"`, `~"devops::create"`, etc.
-- Group: `~"group::source code"`, `~"group::knowledge"`, `~"group::editor"`, etc.
-- Category: `~"Category:Code Analytics"`, `~"Category:DevOps Reports"`, `~"Category:Templates"`, etc.
-- Feature: `~wiki`, `~ldap`, `~api`, `~issues`, `~"merge requests"`, etc.
+- Type. For example: `~feature`, `~bug`, `~tooling`, or `~documentation`.
+- Stage. For example: `~"devops::plan"` or `~"devops::create"`.
+- Group. For example: `~"group::source code"`, `~"group::knowledge"`, or `~"group::editor"`.
+- Category. For example: `~"Category:Code Analytics"`, `~"Category:DevOps Reports"`, or `~"Category:Templates"`.
+- Feature. For example: `~wiki`, `~ldap`, `~api`, `~issues`, or `~"merge requests"`.
 - Department: `~UX`, `~Quality`
 - Team: `~"Technical Writing"`, `~Delivery`
 - Specialization: `~frontend`, `~backend`, `~documentation`
@@ -201,7 +201,7 @@ If you are an expert in a particular area, it makes it easier to find issues to
 work on. You can also subscribe to those labels to receive an email each time an
 issue is labeled with a feature label corresponding to your expertise.
 
-Examples of feature labels are `~wiki`, `~ldap`, `~api`, `~issues`, `~"merge requests"` etc.
+Examples of feature labels are `~wiki`, `~ldap`, `~api`, `~issues`, and `~"merge requests"`.
 
 #### Naming and color convention
 
@@ -223,7 +223,7 @@ The current department labels are:
 
 ### Team labels
 
-**Important**: Most of the historical team labels (e.g. Manage, Plan etc.) are
+**Important**: Most of the historical team labels (like Manage or Plan) are
 now deprecated in favor of [Group labels](#group-labels) and [Stage labels](#stage-labels).
 
 Team labels specify what team is responsible for this issue.
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index a6dcac47910..5e7cccd8e13 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -23,8 +23,8 @@ wireframes of the proposed feature if it will also change the UI.
 
 Merge requests should be submitted to the appropriate project at GitLab.com, for example
 [GitLab](https://gitlab.com/gitlab-org/gitlab/-/merge_requests),
-[GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests),
-[Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests), etc.
+[GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests), or
+[Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests).
 
 If you are new to GitLab development (or web development in general), see the
 [how to contribute](index.md#how-to-contribute) section to get started with
@@ -69,7 +69,7 @@ request is as follows:
       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.
-   1. Include any steps or setup required to ensure reviewers can view the changes you've made (e.g. include any information about feature flags).
+   1. Include any steps or setup required to ensure reviewers can view the changes you've made (for example, include any information about feature flags).
 1. If you're allowed to, set a relevant milestone and [labels](issue_workflow.md).
 1. UI changes should use available components from the GitLab Design System,
    [Pajamas](https://design.gitlab.com/).
@@ -204,7 +204,7 @@ the contribution acceptance criteria below:
    only one working on your feature branch, otherwise merge `main`.
 1. Only one specific issue is fixed or one specific feature is implemented. Do not
    combine things; send separate merge requests for each issue or feature.
-1. Migrations should do only one thing (e.g., create a table, move data to a new
+1. Migrations should do only one thing (for example, create a table, move data to a new
    table, or remove an old table) to aid retrying on failure.
 1. Contains functionality that other users will benefit from.
 1. Doesn't add configuration options or settings options since they complicate making
@@ -214,7 +214,7 @@ the contribution acceptance criteria below:
    - Check for N+1 queries via the SQL log or [`QueryRecorder`](../merge_request_performance_guidelines.md).
    - Avoid repeated access of the file system.
    - Use [polling with ETag caching](../polling.md) if needed to support real-time features.
-1. If the merge request adds any new libraries (gems, JavaScript libraries, etc.),
+1. If the merge request adds any new libraries (like gems or JavaScript libraries),
    they should conform to our [Licensing guidelines](../licensing.md). See those
    instructions for help if the "license-finder" test fails with a
    `Dependencies that need approval` error. Also, make the reviewer aware of the new
@@ -272,7 +272,7 @@ request:
 We allow engineering time to fix small problems (with or without an
 issue) that are incremental improvements, such as:
 
-1. Unprioritized bug fixes (e.g. [Banner alerting of project move is
+1. Unprioritized bug fixes (for example, [Banner alerting of project move is
 showing up everywhere](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18985))
 1. Documentation improvements
 1. Rubocop or Code Quality improvements