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>

2 files changed, 6 insertions, 6 deletions

diff --git a/doc/guides/backporting-to-release-lines.md b/doc/guides/backporting-to-release-lines.md
index 4b5694f0ad..9f48d940cd 100644
--- a/doc/guides/backporting-to-release-lines.md
+++ b/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
diff --git a/doc/releases.md b/doc/releases.md
index d1eeb05876..b555cf4136 100644
--- a/doc/releases.md
+++ b/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