Apply suggestions from code review

Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
nodejs · nodejs-github-bot · Jun 16, 2022 · Jun 15, 2022 · Jun 15, 2022 · Jun 15, 2022
commit 31f38f6b15384ab7c2a4458a154bf90e72476b81
diff --git a/doc/contributing/backporting-to-release-lines.md b/doc/contributing/backporting-to-release-lines.md
@@ -10,7 +10,7 @@ For the active staging branches see the [Release Schedule][].
 
 ## What needs to be backported?
 
-If a cherry-pick from main does not land cleanly on a staging branch, the
+If a cherry-pick from `main` does not land cleanly on a staging branch, the
 releaser will mark the pull request with a particular label for that release
 line (e.g. `backport-requested-vN.x`), specifying to our tooling that this
 pull request should not be included. The releaser will then add a comment

diff --git a/doc/contributing/collaborator-guide.md b/doc/contributing/collaborator-guide.md
@@ -291,7 +291,7 @@ in the form:
   For pull requests, it will look like `refs/pull/PR_NUMBER/head`
   (e.g. for pull request #42 -> `refs/pull/42/head`).
 * `REBASE_ONTO`: Change that to `origin/main` so the pull request gets rebased
-  onto main. This can especially be important for pull requests that have been
+  onto `main`. This can especially be important for pull requests that have been
   open a while.
 
 Look at the list of jobs on the left hand side under "Build History" and copy
@@ -337,7 +337,7 @@ For undocumented APIs that are public, open a pull request documenting the API.
 ### Breaking changes
 
 At least two TSC members must approve backward-incompatible changes to the
-main branch.
+`main` branch.
 
 Examples of breaking changes include:
 
@@ -373,7 +373,7 @@ providing a Public API in such cases.
 #### Unintended breaking changes
 
 Sometimes, a change intended to be non-breaking turns out to be a breaking
-change. If such a change lands on the main branch, a collaborator can revert
+change. If such a change lands on the `main` branch, a collaborator can revert
 it. As an alternative to reverting, the TSC can apply the semver-major label
 after-the-fact.
 
@@ -462,7 +462,7 @@ duration.
 
 Communicate pending deprecations and associated mitigations with the ecosystem
 as soon as possible. If possible, do it before the pull request adding the
-deprecation lands on the main branch.
+deprecation lands on the `main` branch.
 
 Use the `notable-change` label on pull requests that add or change the
 deprecation level of an API.
@@ -670,7 +670,7 @@ for that commit. This is an opportunity to fix commit messages.
       pull request.
     * Protects against the assumption that GitHub will be around forever.
 
-Other changes might have landed on main since the successful CI run. As a
+Other changes might have landed on `main` since the successful CI run. As a
 precaution, run tests (`make -j4 test` or `vcbuild test`).
 
 Confirm that the commit message format is correct using
@@ -755,7 +755,7 @@ the branch.
 Each LTS release has a corresponding branch (v10.x, v8.x, etc.). Each also has a
 corresponding staging branch (v10.x-staging, v8.x-staging, etc.).
 
-Commits that land on main are cherry-picked to each staging branch as
+Commits that land on `main` are cherry-picked to each staging branch as
 appropriate. If a change applies only to the LTS branch, open the pull request
 against the _staging_ branch. Commits from the staging branch land on the LTS
 branch only when a release is being prepared. They might land on the LTS branch

diff --git a/doc/contributing/commit-queue.md b/doc/contributing/commit-queue.md
@@ -8,7 +8,7 @@ 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,
-the Action will rebase it and push to main.
+the Action will rebase it and push to `main`.
 
 This document gives an overview of how the Commit Queue works, as well as
 implementation details, reasoning for design choices, and current limitations.

diff --git a/doc/contributing/diagnostic-tooling-support-tiers.md b/doc/contributing/diagnostic-tooling-support-tiers.md
@@ -14,7 +14,7 @@ the following tiers.
   suite for the tool/API is not green. To be considered for inclusion
   in this tier it must have a good test suite and that test suite and a job
   must exist in the Node.js CI so that it can be run as part of the release
-  process.  Tests on main will be run nightly when possible to provide
+  process. Tests on `main` will be run nightly when possible to provide
   early warning of potential issues.  No commit to the current and LTS
   release branches should break this tool/API if the next major release
   is within 1 month. In addition:

diff --git a/doc/contributing/maintaining-V8.md b/doc/contributing/maintaining-V8.md
@@ -345,13 +345,13 @@ to apply a minor update.
 
 ### Major updates
 
-We upgrade the version of V8 in Node.js main whenever a V8 release goes stable
+We upgrade the version of V8 in Node.js `main` whenever a V8 release goes stable
 upstream, that is, whenever a new release of Chrome comes out.
 
 Upgrading major versions would be much harder to do with the patch mechanism
 above. A better strategy is to
 
-1. Audit the current main branch and look at the patches that have been
+1. Audit the current `main` branch and look at the patches that have been
    floated since the last major V8 update.
 2. Replace the copy of V8 in Node.js with a fresh checkout of the latest stable
    V8 branch. Special care must be taken to recursively update the DEPS that V8
@@ -394,7 +394,7 @@ branches. This has several benefits:
 * The history of the V8 branch in `nodejs/v8` becomes purer and it would make it
   easier to pull in the V8 team for help with reviewing.
 * It would make it simpler to setup an automated build that tracks Node.js
-  main + V8 lkgr integration build.
+  `main` + V8 lkgr integration build.
 
 This would require some tooling to:
 

diff --git a/doc/contributing/maintaining-openssl.md b/doc/contributing/maintaining-openssl.md
@@ -5,7 +5,7 @@ This document describes how to update `deps/openssl/`.
 If you need to provide updates across all active release lines you will
 currently need to generate four PRs as follows:
 
-* a PR for main which is generated following the instructions
+* a PR for `main` which is generated following the instructions
   below for OpenSSL 3.x.x.
 * a PR for 16.x following the instructions in the v16.x-staging version
   of this guide.

diff --git a/doc/contributing/writing-and-running-benchmarks.md b/doc/contributing/writing-and-running-benchmarks.md
@@ -256,7 +256,7 @@ As an example on how to check for a possible performance improvement, the
 an example. This pull request _claims_ to improve the performance of the
 `node:string_decoder` module.
 
-First build two versions of Node.js, one from the main branch (here called
+First build two versions of Node.js, one from the `main` branch (here called
 `./node-main`) and another with the pull request applied (here called
 `./node-pr-5134`).
 

diff --git a/doc/contributing/writing-tests.md b/doc/contributing/writing-tests.md
@@ -469,7 +469,7 @@ will depend on what is being tested if this is required or not.
 To generate a test coverage report, see the
 [Test Coverage section of the Building guide][].
 
-Nightly coverage reports for the Node.js main branch are available at
+Nightly coverage reports for the Node.js `main` branch are available at
 <https://coverage.nodejs.org/>.
 
 [ASCII]: https://man7.org/linux/man-pages/man7/ascii.7.html