Docs: fix linting errors in doc/user/project/issues/managing_issues.md

doc/user/project/issues/managing_issues.md

@@ -19,16 +19,16 @@ Key actions for issues include:
 
 ## Create a new issue
 
-When you create a new issue, you'll be prompted to fill in the [data and fields of the issue](issue_data_and_actions.md),
+When you create a new issue, you are prompted to fill in the [data and fields of the issue](issue_data_and_actions.md),
 as illustrated below. If you know the values you want to assign to an issue, you can use the
-[Quick actions](../quick_actions.md) feature to input values, instead of selecting them from lists.
+[Quick actions](../quick_actions.md) feature to input values.
 
 While creating an issue, you can associate it to an existing epic from current group by
 selecting it using **Epic** dropdown.
 
 ### Accessing the New Issue form
 
-There are many ways to get to the New Issue form from within a project:
+There are many ways to get to the New Issue form from a project's page:
 
 - Navigate to your **Project's Dashboard** > **Issues** > **New Issue**:
 
@@ -75,9 +75,8 @@ using the dropdown button at the top-right of the page.
 
 ![Select project to create issue](img/select_project_from_group_level_issue_tracker.png)
 
-We'll keep track of the project you selected most recently, and use it as the default
-for your next visit. This should save you a lot of time and clicks, if you mostly
-create issues for the same project.
+The project you selected most recently becomes the default for your next visit.
+This should save you a lot of time and clicks, if you mostly create issues for the same project.
 
 ![Create issue from group-level issue tracker](img/create_issue_from_group_level_issue_tracker.png)
 
@@ -90,22 +89,22 @@ the appropriate project and followed up from there.
 ### New issue via email
 
 A link to **Email a new issue to this project** is displayed at the bottom of a project's
-**Issues List** page, if your GitLab instance has [incoming email](../../../administration/incoming_email.md)
-configured.
+**Issues List** page. The link is shown only if your GitLab instance has [incoming email](../../../administration/incoming_email.md)
+configured and there is at least one issue in the issue list.
 
 ![Bottom of a project issues page](img/new_issue_from_email.png)
 
 When you click this link, an email address is generated and displayed, which should be used
 by **you only**, to create issues in this project. You can save this address as a
-contact in your email client for easy access.
+contact in your email client for quick access.
 
 WARNING:
 This is a private email address, generated just for you. **Keep it to yourself**,
 as anyone who knows it can create issues or merge requests as if they
-were you. If the address is compromised, or you'd like it to be regenerated for
-any reason, click **Email a new issue to this project** again and click the reset link.
+were you. If the address is compromised, or you want to regenerate it,
+click **Email a new issue to this project**, followed by **reset it**.
 
-Sending an email to this address will create a new issue in your name for
+Sending an email to this address creates a new issue associated with your account for
 this project, where:
 
 - The email subject becomes the issue title.
@@ -118,15 +117,15 @@ older format is still supported, allowing existing aliases or contacts to contin
 
 ### New issue via URL with prefilled fields
 
-You can link directly to the new issue page for a given project, with prefilled
-field values using query string parameters in a URL. This is useful for embedding
-a URL in an external HTML page, and also certain scenarios where you want the user to
-create an issue with certain fields prefilled.
+To link directly to the new issue page with prefilled fields, use query
+string parameters in a URL. You can embed a URL in an external
+HTML page, or create issues with certain
+fields prefilled.
 
 The title, description, description template, and confidential fields can be prefilled
 using this method. You cannot pre-fill both the description and description template
-fields in the same URL (since a description template also populates the description
-field).
+fields in the same URL because a description template also populates the description
+field.
 
 | Field                | URL Parameter Name    | Notes                                                 |
 |----------------------|-----------------------|-------------------------------------------------------|
@@ -147,9 +146,9 @@ Follow these examples to form your new issue URL with prefilled fields.
 
 ## Moving Issues
 
-Moving an issue will copy it to a new location (project), and close it in the old project,
-but it will not be deleted. There will also be a system note added to both issues
-indicating where it came from and went to.
+Moving an issue copies it to the target project, and closes it in the originating project.
+The original issue is not deleted. A system note, which indicates
+where it came from and went to, is added to both issues.
 
 The "Move issue" button is at the bottom of the right-sidebar when viewing the issue.
 
@@ -157,7 +156,9 @@ The "Move issue" button is at the bottom of the right-sidebar when viewing the i
 
 ### Moving Issues in Bulk
 
-If you have advanced technical skills you can also bulk move all the issues from one project to another in the rails console. The below script will move all the issues from one project to another that are not in status **closed**.
+If you have advanced technical skills you can also bulk move all the issues from
+one project to another in the rails console. The below script moves all issues
+that are not in status **closed** from one project to another.
 
 To access rails console run `sudo gitlab-rails console` on the GitLab server and run the below
 script. Please be sure to change `project`, `admin_user`, and `target_project` to your values.
@@ -193,23 +194,18 @@ from its list and dropping it into the **Closed** list.
 
 ### Closing issues automatically
 
-NOTE:
-For performance reasons, automatic issue closing is disabled for the very first
-push from an existing repository.
-
-When a commit or merge request resolves one or more issues, it is possible to have
-these issues closed automatically when the commit or merge request reaches the project's
-default branch.
+When a commit or merge request resolves issues, the issues
+can be closed automatically when the commit reaches the project's default branch.
 
 If a commit message or merge request description contains text matching a [defined pattern](#default-closing-pattern),
-all issues referenced in the matched text will be closed. This happens when the commit
+all issues referenced in the matched text are closed. This happens when the commit
 is pushed to a project's [**default** branch](../repository/branches/index.md#default-branch),
 or when a commit or merge request is merged into it.
 
 For example, if `Closes #4, #6, Related to #5` is included in a Merge Request
-description, issues `#4` and `#6` will close automatically when the MR is merged, but not `#5`.
+description, issues `#4` and `#6` are closed automatically when the MR is merged, but not `#5`.
 Using `Related to` flags `#5` as a [related issue](related_issues.md),
-but it will not close automatically.
+but is not closed automatically.
 
 ![merge request closing issue when merged](img/merge_request_closes_issue.png)
 
@@ -219,9 +215,12 @@ If the issue is in a different repository than the MR, add the full URL for the
 Closes #4, #6, and https://gitlab.com/<username>/<projectname>/issues/<xxx>
 ```
 
+For performance reasons, automatic issue closing is disabled for the very first
+push from an existing repository.
+
 #### Default closing pattern
 
-When not specified, the default issue closing pattern as shown below will be used:
+When not specified, this default issue closing pattern is used:
 
 ```shell
 \b((?:[Cc]los(?:e[sd]?|ing)|\b[Ff]ix(?:e[sd]|ing)?|\b[Rr]esolv(?:e[sd]?|ing)|\b[Ii]mplement(?:s|ed|ing)?)(:?) +(?:(?:issues? +)?%{issue_ref}(?:(?: *,? +and +| *,? *)?)|([A-Z][A-Z0-9_]+-\d+))+)
@@ -251,8 +250,8 @@ This commit is also related to #17 and fixes #18, #19
 and https://gitlab.example.com/group/otherproject/issues/23.
 ```
 
-will close `#18`, `#19`, `#20`, and `#21` in the project this commit is pushed to,
-as well as `#22` and `#23` in `group/otherproject`. `#17` won't be closed as it does
+closes `#18`, `#19`, `#20`, and `#21` in the project this commit is pushed to,
+as well as `#22` and `#23` in `group/otherproject`. `#17` is not closed as it does
 not match the pattern. It works with multi-line commit messages as well as one-liners
 when used from the command line with `git commit -m`.
 
@@ -261,14 +260,14 @@ when used from the command line with `git commit -m`.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/19754) in GitLab 12.7.
 
 The automatic issue closing feature can be disabled on a per-project basis
-within the [project's repository settings](../settings/index.md). Referenced
-issues will still be displayed as such but won't be closed automatically.
+in the [project's repository settings](../settings/index.md). Referenced
+issues are still displayed, but are not closed automatically.
 
 ![disable issue auto close - settings](img/disable_issue_auto_close.png)
 
 This only applies to issues affected by new merge requests or commits. Already
 closed issues remain as-is. Disabling automatic issue closing only affects merge
-requests *within* the project and won't prevent other projects from closing it
+requests *in* the project and does not prevent other projects from closing it
 via cross-project issues.
 
 #### Customizing the issue closing pattern **(CORE ONLY)**