doc: clarify release process for new releasers

Author: RafaelGSS

doc/contributing/releases.md

@@ -448,6 +448,23 @@ testing is required. Use this opportunity particularly to test macOS and Windows
 installers if there are any concerns. Click through to the individual workers
 for a run to find the artifacts.
 
+Release build list
+
+| name                                       | OS            |
+| ------------------------------------------ | ------------- |
+| rhel8-release-sources                      | Linux x64     |
+| osx1015-release-tar                        | macOS 10.15   |
+| vs2019-x64                                 | Windows x64   |
+| cross-compiler-rhel8-arm7-gcc-8-glibc-2.28 | Linux ARMv7   |
+| rhel8-s390x-release                        | Linux s390x   |
+| vs2019-x86                                 | Windows x86   |
+| aix72-ppc64                                | AIX 7.2       |
+| rhel8-ppc64le-release                      | Linux ppc64le |
+| rhel8-x64-release                          | Linux x64     |
+| osx11-release-tar                          | macOS 11      |
+| rhel8-arm64-release                        | Linux ARM64   |
+| osx11-release-pkg                          | macOS 11      |
+
 All release workers should achieve "SUCCESS" (and be green, not red). A release
 with failures should not be promoted as there are likely problems to be
 investigated.
@@ -468,7 +485,14 @@ failed build if you start again!
 Jenkins collects the artifacts from the builds, allowing you to download and
 install the new build. Make sure that the build appears correct. Check the
 version numbers, and perform some basic checks to confirm that all is well with
-the build before moving forward.
+the build before moving forward. Use the following list as a baseline:
+
+* `process.version` is as expected
+* `process.release` is as expected
+* `process.versions` is as expected (for example, `openssl` or `llhttp` version
+  must be in the expected updated version)
+* npm version (check it matches what we expect)
+* Basic usage to confirm the binary works (`console.log` and global methods)
 
 ### 11. Tag and sign the release commit
 
@@ -510,6 +534,8 @@ include the release code name.
 The tag **must** be signed using the GPG key that's listed for you on the
 project README.
 
+**Note**: Don't push the tag to remote at this point.
+
 ### 12. Set up for the next release
 
 On release proposal branch, edit `src/node_version.h` again and: