docs: Update release documentation (#18174)

* docs: Update release documentation

* Fix lint error

docs/src/maintain/manage-releases.md

@@ -30,28 +30,13 @@ The release manager needs to have access to ESLint's two-factor authentication f
 
 ## Release Communication
 
-Each scheduled release should be associated with a release issue ([example](https://github.com/eslint/eslint/issues/8138)). The release issue is the source of information for the team about the status of a release. Be sure the release issue has the "release" label so that it's easy to find.
+Each scheduled release is associated with an autogenerated release issue ([example](https://github.com/eslint/eslint/issues/18151)). The release issue is the source of information for the team about the status of a release and contains a checklist that the release manager should follow.
 
 ## Process
 
-On the day of a scheduled release, the release manager should follow these steps:
-
-1. Review open pull requests to see if any should be merged. In general, you can merge pull requests that:
-    * Have been open for at least two days and approved (these are just waiting for merge).
-    * Important pull requests (as determined by the team). You should stop and have people review before merging if they haven't been already.
-    * Documentation changes.
-    * Small bugfixes written by a team member.
-1. Log into Jenkins and schedule a build for the "ESLint Release" job.
-1. Watch the console output of the build on Jenkins. At some point, the build will pause and a link will be produced with an input field for a six-digit 2FA code.
-1. Enter the current six-digit 2FA code from your authenticator app.
-1. Continue the build and wait for it to finish.
-1. Update the release blog post with a "Highlights" section, including new rules and anything else that's important.
-1. Make a release announcement in the public chatroom.
-1. Make a release announcement on Twitter.
-1. Make a release announcement on the release issue. Document any problems that occurred during the release, and remind the team not to merge anything other than documentation changes and bugfixes. Leave the release issue open.
-1. Add the `patch release pending` label to the release issue. (When this label is present, `eslint-github-bot` will create a pending status check on non-semver-patch pull requests, to ensure that they aren't accidentally merged while a patch release is pending.)
-
-All release-related communications occur in the `#team` channel on Discord.
+On the day of a scheduled release, the release manager should follow the steps in the release issue.
+
+All release-related communications occur in a thread in the `#team` channel on Discord.
 
 On the Monday following the scheduled release, the release manager needs to determine if a patch release is necessary. A patch release is considered necessary if any of the following occurred since the scheduled release:
 
@@ -71,3 +56,12 @@ An emergency release is unplanned and isn't the regularly scheduled release or t
 In general, we try not to do emergency releases. Even if there is a regression, it's best to wait until Monday to see if any other problems arise so a patch release can fix as many issues as possible.
 
 The only real exception is if ESLint is completely unusable by most of the current users. For instance, we once pushed a release that errored for everyone because it was missing some core files. In that case, an emergency release is appropriate.
+
+## Troubleshooting
+
+### `npm publish` returns a 404
+
+This typically happens due to a permission error related to the npm token.
+
+* `release-please` uses a granular access token that expires after a year. This token is tied to the `eslintbot` npm account and needs to be regenerated every year in March. If the access token is expired, `npm publish` returns a 404.
+* Jenkins uses a classic access token without an expiration date, but it does require a 2FA code to publish. If the 2FA code is incorrect, then `npm publish` returns a 404.