Add latest changes from gitlab-org/gitlab@master

4 files changed, 5 insertions, 5 deletions

diff --git a/doc/development/cicd/templates.md b/doc/development/cicd/templates.md
index 0169ca42ac6..44bbd4c83f0 100644
--- a/doc/development/cicd/templates.md
+++ b/doc/development/cicd/templates.md
@@ -13,7 +13,7 @@ This document explains how to develop [GitLab CI/CD templates](../../ci/examples
 
 All template files reside in the `lib/gitlab/ci/templates` directory, and are categorized by the following sub-directories:
 
-| Sub-directroy | Content                                                      | [Selectable in UI](#make-sure-the-new-template-can-be-selected-in-ui) |
+| Sub-directory | Content                                                      | [Selectable in UI](#make-sure-the-new-template-can-be-selected-in-ui) |
 |---------------|--------------------------------------------------------------|-----------------------------------------------------------------------|
 | `/AWS/*`      | Cloud Deployment (AWS) related jobs                          | No                                                                    |
 | `/Jobs/*`     | Auto DevOps related jobs                                     | Yes                                                                   |
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 283f88ec0e1..9a18af34866 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -138,7 +138,7 @@ up confusion or verify that the end result matches what they had in mind, to
 database specialists to get input on the data model or specific queries, or to
 any other developer to get an in-depth review of the solution.
 
-If an author is unsure if a merge request needs a [domain experts's](#domain-experts) opinion, that's
+If an author is unsure if a merge request needs a [domain expert's](#domain-experts) opinion, that's
 usually a pretty good sign that it does, since without it the required level of
 confidence in their solution will not have been reached.
 
diff --git a/doc/development/documentation/styleguide.md b/doc/development/documentation/styleguide.md
index 4c77d95c89f..d37c00ef69b 100644
--- a/doc/development/documentation/styleguide.md
+++ b/doc/development/documentation/styleguide.md
@@ -1288,7 +1288,7 @@ However, the following might help the reader connect the text to the user interf
 | **{monitor}** Monitoring | View GitLab system information, and information on background jobs, logs, health checks, requests profiles, and audit logs. |
 | **{messages}** Messages  | Send and manage broadcast messages for your users.                                                                          |
 
-Use an icon when you find youself having to describe an interface element. For example:
+Use an icon when you find yourself having to describe an interface element. For example:
 
 - Do: Click the Admin Area icon ( **{admin}** ).
 - Don't: Click the Admin Area icon (the wrench icon).
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index e7954fa910b..6616c350e2b 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -929,7 +929,7 @@ export default {
 
 - We can use slots and/or scoped slots to achieve the same thing as we did with mixins. If you only need an EE component there is no need to create the CE component.
 
-1. First, we have a CE component that can render a slot incase we need EE template and functionality to be decorated on top of the CE base.
+1. First, we have a CE component that can render a slot in case we need EE template and functionality to be decorated on top of the CE base.
 
 ```vue
 // ./ce/my_component.vue
@@ -1030,7 +1030,7 @@ separate SCSS file in an appropriate directory within `app/assets/stylesheets`.
 
 In some cases, this is not entirely possible or creating dedicated SCSS file is an overkill,
 e.g. a text style of some component is different for EE. In such cases,
-styles are usually kept in stylesheet that is common for both CE and EE, and it is wise
+styles are usually kept in a stylesheet that is common for both CE and EE, and it is wise
 to isolate such ruleset from rest of CE rules (along with adding comment describing the same)
 to avoid conflicts during CE to EE merge.