doc: standardize on _pull request_

Sometimes we capitalize _pull request_ and sometimes we don't.
Standardize on lowercase based on Microsoft Style Guide, Chicago Manual
of Style, and GitHub's own docs and UI.

Refs: https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
Refs: https://docs.github.com/en/github/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request
Refs: https://docs.microsoft.com/en-us/style-guide/capitalization

PR-URL: #39384
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Zeyu Yang <himself65@outlook.com>
Reviewed-By: Harshitha K P <harshitha014@gmail.com>
Reviewed-By: Zijian Liu <lxxyxzj@gmail.com>

Author: Trott

BUILDING.md

@@ -311,7 +311,7 @@ $ make test-only
 
 At this point, you are ready to make code changes and re-run the tests.
 
-If you are running tests before submitting a Pull Request, the recommended
+If you are running tests before submitting a pull request, the recommended
 command is:
 
 ```console

doc/guides/collaborator-guide.md

@@ -488,7 +488,7 @@ The TSC serves as the final arbiter where required.
    who wish to land their own pull requests will self-assign them. Sometimes, an
    author will delegate to someone else. If in doubt, ask the assignee whether
    it is okay to land.
-1. Never use GitHub's green ["Merge Pull Request"][] button. Reasons for not
+1. Never use GitHub's green ["Merge pull request"][] button. Reasons for not
    using the web interface button:
    * The "Create a merge commit" method will add an unnecessary merge commit.
    * The "Squash and merge" method will add metadata (the pull request #) to the
@@ -911,7 +911,7 @@ need to be attached anymore, as only important bugfixes will be included.
   * `arm`, `mips`, `s390`, `ppc`
   * No `x86{_64}` label because it is the implied default
 
-["Merge Pull Request"]: https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-request-on-github
+["Merge pull request"]: https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-request-on-github
 [Deprecation]: https://en.wikipedia.org/wiki/Deprecation
 [SECURITY.md]: https://github.com/nodejs/node/blob/HEAD/SECURITY.md
 [Stability Index]: ../api/documentation.md#stability-index

doc/guides/commit-queue.md

@@ -2,12 +2,12 @@
 
 > Stability: 1 - Experimental
 
-*tl;dr: You can land Pull Requests by adding the `commit-queue` label to it.*
+*tl;dr: You can land pull requests by adding the `commit-queue` label to it.*
 
 Commit Queue is an experimental feature for the project which simplifies the
 landing process by automating it via GitHub Actions. With it, collaborators can
-land Pull Requests by adding the `commit-queue` label to a PR. All
-checks will run via node-core-utils, and if the Pull Request is ready to land,
+land pull requests by adding the `commit-queue` label to a PR. All
+checks will run via node-core-utils, and if the pull request is ready to land,
 the Action will rebase it and push to master.
 
 This document gives an overview of how the Commit Queue works, as well as
@@ -17,8 +17,8 @@ implementation details, reasoning for design choices, and current limitations.
 
 From a high-level, the Commit Queue works as follow:
 
-1. Collaborators will add `commit-queue` label to Pull Requests ready to land
-2. Every five minutes the queue will do the following for each Pull Request
+1. Collaborators will add `commit-queue` label to pull requests ready to land
+2. Every five minutes the queue will do the following for each pull request
    with the label:
    1. Check if the PR also has a `request-ci` label (if it has, skip this PR
       since it's pending a CI run)
@@ -40,10 +40,10 @@ From a high-level, the Commit Queue works as follow:
 ## Current limitations
 
 The Commit Queue feature is still in early stages, and as such it might not
-work for more complex Pull Requests. These are the currently known limitations
+work for more complex pull requests. These are the currently known limitations
 of the commit queue:
 
-1. All commits in a Pull Request must either be following commit message
+1. All commits in a pull request must either be following commit message
    guidelines or be a valid [`fixup!`](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---fixupltcommitgt)
    commit that will be correctly handled by the [`--autosquash`](https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt---autosquash)
    option
@@ -73,7 +73,7 @@ reasons:
 `node-core-utils` is configured with a personal token and
 a Jenkins token from
 [@nodejs-github-bot](https://github.com/nodejs/github-bot).
-`octokit/graphql-action` is used to fetch all Pull Requests with the
+`octokit/graphql-action` is used to fetch all pull requests with the
 `commit-queue` label. The output is a JSON payload, so `jq` is used to turn
 that into a list of PR ids we can pass as arguments to
 [`commit-queue.sh`](../../tools/actions/commit-queue.sh).
@@ -87,8 +87,8 @@ that into a list of PR ids we can pass as arguments to
 1. The repository owner
 2. The repository name
 3. The Action GITHUB_TOKEN
-4. Every positional argument starting at this one will be a Pull Request ID of
-    a Pull Request with commit-queue set.
+4. Every positional argument starting at this one will be a pull request ID of
+    a pull request with commit-queue set.
 
 The script will iterate over the pull requests. `ncu-ci` is used to check if
 the last CI is still pending, and calls to the GitHub API are used to check if