doc: fix links in some intra-repository docs

PR-URL: https://github.com/nodejs/node/pull/15675
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

COLLABORATOR_GUIDE.md

@@ -8,7 +8,7 @@
    - [Internal vs. Public API](#internal-vs-public-api)
    - [Breaking Changes](#breaking-changes)
    - [Deprecations](#deprecations)
-   - [Involving the TSC](#involving-the-TSC)
+   - [Involving the TSC](#involving-the-tsc)
 * [Landing Pull Requests](#landing-pull-requests)
    - [Technical HOWTO](#technical-howto)
    - [I Just Made a Mistake](#i-just-made-a-mistake)
@@ -367,7 +367,7 @@ The TSC should serve as the final arbiter where required.
 
 ## Landing Pull Requests
 
-* Please never use GitHub's green ["Merge Pull Request"](https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-request-using-the-github-web-interface) button.
+* Please never use GitHub's green ["Merge Pull Request"](https://help.github.com/articles/merging-a-pull-request/#merging-a-pull-request-on-github) button.
   * If you do, please force-push removing the merge.
   * Reasons for not using the web interface button:
     * The merge method will add an unnecessary merge commit.
@@ -394,8 +394,8 @@ information regarding the change process:
   - Useful for @mentions / contact list if something goes wrong in the PR.
   - Protects against the assumption that GitHub will be around forever.
 
-Review the commit message to ensure that it adheres to the guidelines
-outlined in the [contributing](./CONTRIBUTING.md#step-3-commit) guide.
+Review the commit message to ensure that it adheres to the guidelines outlined
+in the [contributing](./CONTRIBUTING.md#commit-message-guidelines) guide.
 
 See the commit log for examples such as
 [this one](https://github.com/nodejs/node/commit/b636ba8186) if unsure
@@ -520,7 +520,7 @@ commit message for that commit. This is a good moment to fix incorrect
 commit logs, ensure that they are properly formatted, and add
 `Reviewed-By` lines.
 * The commit message text must conform to the
-[commit message guidelines](./CONTRIBUTING.md#step-3-commit).
+[commit message guidelines](./CONTRIBUTING.md#commit-message-guidelines).
 
 Run tests (`make -j4 test` or `vcbuild test`). Even though there was a
 successful continuous integration run, other changes may have landed on master
@@ -594,7 +594,8 @@ commit final.
 Long Term Support (often referred to as *LTS*) guarantees application developers
 a 30 month support cycle with specific versions of Node.js.
 
-You can find more information [in the full LTS plan](https://github.com/nodejs/lts#lts-plan).
+You can find more information
+[in the full release plan](https://github.com/nodejs/Release#release-plan).
 
 #### How does LTS work?
 
@@ -674,5 +675,5 @@ release. This process of making a release will be a collaboration between the
 LTS working group and the Release team.
 
 [backporting guide]: doc/guides/backporting-to-release-lines.md
-[Stability Index]: https://github.com/nodejs/node/pull/doc/api/documentation.md#stability-index
+[Stability Index]: doc/api/documentation.md#stability-index
 [Enhancement Proposal]: https://github.com/nodejs/node-eps

doc/guides/backporting-to-release-lines.md

@@ -6,7 +6,7 @@ Each release line has a staging branch that the releaser will use as a scratch
 pad while preparing a release. The branch name is formatted as follows:
 `vN.x-staging` where `N` is the major release number.
 
-*Note*: For the active staging branches see the [LTS Schedule][].
+*Note*: For the active staging branches see the [Release Schedule][].
 
 ## What needs to be backported?
 
@@ -19,7 +19,7 @@ requesting that a backport pull request be made.
 ## What can be backported?
 
 The "Current" release line is much more lenient than the LTS release lines in
-what can be landed. Our LTS release lines (see the [LTS Plan][])
+what can be landed. Our LTS release lines (see the [Release Plan][])
 require that commits mature in the Current release for at least 2 weeks before
 they can be landed in an LTS staging branch. Only after "maturation" will those
 commits be cherry-picked or backported.
@@ -81,6 +81,6 @@ hint: and commit the result with 'git commit'
 After the PR lands replace the `backport-requested-v6.x` label on the original
 PR with `backported-to-v6.x`.
 
-[LTS Schedule]: https://github.com/nodejs/LTS/#lts-schedule1
-[LTS Plan]: https://github.com/nodejs/LTS#lts-plan
+[Release Schedule]: https://github.com/nodejs/Release#release-schedule1
+[Release Plan]: https://github.com/nodejs/Release#release-plan
 [`node-test-pull-request`]: https://ci.nodejs.org/job/node-test-pull-request/build

doc/releases.md

@@ -291,7 +291,7 @@ If you didn't wait for ARM builds in the previous step before promoting the rele
 
 ### 13. Check the Release
 
-Your release should be available at <https://nodejs.org/dist/vx.y.z/> and <https://nodejs.org/dist/latest/>. Check that the appropriate files are in place. You may want to check that the binaries are working as appropriate and have the right internal version strings. Check that the API docs are available at <https://nodejs.org/api/>. Check that the release catalog files are correct at <https://nodejs.org/dist/index.tab> and <https://nodejs.org/dist/index.json>.
+Your release should be available at `https://nodejs.org/dist/vx.y.z/` and <https://nodejs.org/dist/latest/>. Check that the appropriate files are in place. You may want to check that the binaries are working as appropriate and have the right internal version strings. Check that the API docs are available at <https://nodejs.org/api/>. Check that the release catalog files are correct at <https://nodejs.org/dist/index.tab> and <https://nodejs.org/dist/index.json>.
 
 ### 14. Create a Blog Post
 
@@ -312,7 +312,7 @@ Refs: <full URL to your release proposal PR>
 
 ### 15. Announce
 
-The nodejs.org website will automatically rebuild and include the new version. To announce the build on Twitter through the official @nodejs account, email [pr@nodejs.org](pr@nodejs.org) with a message such as:
+The nodejs.org website will automatically rebuild and include the new version. To announce the build on Twitter through the official @nodejs account, email [pr@nodejs.org](mailto:pr@nodejs.org) with a message such as:
 
 > v5.8.0 of @nodejs is out: https://nodejs.org/en/blog/release/v5.8.0/ … something here about notable changes