Missed a note: re-requesting review

.github/CONTRIBUTING.md

@@ -80,36 +80,36 @@ Then:
 ### 🎋 Initial Creation
 
 1. Create a new branch in your working copy.
-  Give your branch a descriptive name, such as `issue/12345`: `git checkout -b issue/12345`.
+   Give your branch a descriptive name, such as `issue/12345`: `git checkout -b issue/12345`.
 1. Make your changes and add them via `git add`.
    - Your changes will likely be somewhere in `lib/`, `bin/` or `browser-entry.js` (if your changes are browser-specific).
    - Unit and/or integration **tests are required** for any code change.
-   These live in `test/`.
+     These live in `test/`.
    - **Do not modify** the root `mocha.js` file directly; it is automatically generated.
    - Keep your PR focused.
-   Don't fix two things at once; don't upgrade dependencies unless necessary.
+     Don't fix two things at once; don't upgrade dependencies unless necessary.
 1. Before committing, run `npm start test`.
    - This will run both Node.js-based and browser-based tests.
    - Ultimately, your pull request will be built on our continuous integration servers ([GitHub Actions](https://github.com/mochajs/mocha/actions?query=workflow%3A%22Tests%22)).
-   The first step to ensuring these checks pass is to test on your own machine.
+     The first step to ensuring these checks pass is to test on your own machine.
    - A coverage check will be sent to [Coveralls](https://coveralls.io/github/mochajs/mocha).
-    **A drop in code coverage % is considered a failed check**.
+     **A drop in code coverage % is considered a failed check**.
 1. Commit your changes.
    - Use a brief message on the first line, referencing a relevant issue (e.g. `closes #12345`).
    - Add detail in subsequent lines.
    - A pre-commit hook will run which automatically formats your staged changes (and fixes any problems it can) with ESLint and Prettier.
-    If ESLint fails to fix an issue, your commit will fail and you will need to manually correct the problem.
+     If ESLint fails to fix an issue, your commit will fail and you will need to manually correct the problem.
 1. <a name="up-to-date"/> (Optional) Ensure you are up-to-date with Mocha's `master` branch:
    - You can add an "upstream" remote repo using `git remote add upstream https://github.com/mochajs/mocha.git && git fetch upstream`.
    - Navigate to your `master` branch using `git checkout master`.
    - Pull changes from `upstream` using `git pull upstream master`.
    - If any changes were pulled in, rebase your branch onto `master` by switching back to your branch (`git checkout <your-branch>`) then rebasing using `git rebase master`.
 1. Push your changes to your fork; `git push origin`.
 1. In your browser, navigate to [mochajs/mocha](https://github.com/mochajs/mocha).
-  You should see a notification about your recent changes in your fork's branch, with a (green?) button to create a pull request.
-  Click it.
+   You should see a notification about your recent changes in your fork's branch, with a (green?) button to create a pull request.
+   Click it.
 1. Describe your changes in detail here, following the template.
-  Once you're satisfied, submit the form.
+   Once you're satisfied, submit the form.
 
 At that point, hooray! 🎉
 You should see a pull request on github.com/mochajs/mocha/pulls.
@@ -119,22 +119,23 @@ You should see a pull request on github.com/mochajs/mocha/pulls.
 Now that the pull request exists, some tasks will be run on it:
 
 1. If you have not signed our [Contributor License Agreement](https://js.foundation/cla), a friendly robot will prompt you to do so.
-  A [CLA](https://cla.js.foundation/mochajs/mocha) (electronic) signature is **required** for all contributions of code to Mocha.
+   A [CLA](https://cla.js.foundation/mochajs/mocha) (electronic) signature is **required** for all contributions of code to Mocha.
 1. Continuous integration checks will run against your changes.
-  The result of these checks will be displayed on your PR.
+   The result of these checks will be displayed on your PR.
    - If the checks fail, you must address those before the PR is accepted.
    - GitHub will indicate if there's a conflict.
-    If this happens, you will need to [rebase](https://help.github.com/articles/about-git-rebase) your branch onto the `master` branch of the source repository.
-    **Do not `git merge`**.
+     If this happens, you will need to [rebase](https://help.github.com/articles/about-git-rebase) your branch onto the `master` branch of the source repository.
+     **Do not `git merge`**.
    - (Optional) [Squash](https://help.github.com/articles/about-pull-request-merges/#squash-and-merge-your-pull-request-commits) your changesets.
-    If you have multiple changesets in your PR, they will be squashed upon PR acceptance by the Mocha team.
+     If you have multiple changesets in your PR, they will be squashed upon PR acceptance by the Mocha team.
 1. Be patient while your PR is reviewed.
-  This can take a while.
-  We may request changes, but don't be afraid to question them.
+   This can take a while.
+   We may request changes, but don't be afraid to question them.
 1. Your PR might become conflicted with the code in `master`.
-  If this is the case, you will need to [update your PR](#up-to-date) and resolve your conflicts.
+   If this is the case, you will need to [update your PR](#up-to-date) and resolve your conflicts.
 1. You don't need to make a new PR to any needed changes.
-  Instead, commit on top of your changes, and push these to your fork's branch.
-  The PR will be updated, and CI will re-run.
+   Instead, commit on top of your changes, and push these to your fork's branch.
+   The PR will be updated, and CI will re-run.
+1. Once you've addressed all the feedback you can, [re-request review on GitHub](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews#re-requesting-a-review).
 
 Join us in the [contributors' chat](https://gitter.im/mochajs/contributors)!