doc: add build wg info to releases.md

PR-URL: #21275
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Matheus Marchini <matheus@sthima.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>

doc/releases.md

@@ -81,6 +81,23 @@ Notes:
 - Version strings are listed below as _"vx.y.z"_. Substitute for the release
   version.
 
+### 0. Pre-release steps
+
+Before preparing a Node.js release, the Build Working Group must be notified at
+least one business day in advance of the expected release. Coordinating with
+Build is essential to make sure that the CI works, release files are published,
+and the release blog post is available on the project website.
+
+Build can be contacted best by opening up an issue on the [Build issue tracker][],
+and by posting in `#node-build` on [webchat.freenode.net][].
+
+When preparing a security release, contact Build at least two weekdays in
+advance of the expected release. To ensure that the security patch(es) can be
+properly tested, run a `node-test-pull-request` job against the `master` branch
+of the `nodejs-private/node-private` repository a day or so before the
+[CI lockdown procedure][] begins. This is to confirm that Jenkins can properly
+access the private repository.
+
 ### 1. Cherry-picking from `master` and other branches
 
 Create a new branch named _"vx.y.z-proposal"_, or something similar. Using `git
@@ -517,4 +534,7 @@ Close your release proposal PR and remove the proposal branch.
 
 _In whatever form you do this..._
 
+[CI lockdown procedure]: https://github.com/nodejs/build/blob/master/doc/jenkins-guide.md#restricting-access-for-security-releases
+[Build issue tracker]: https://github.com/nodejs/build/issues/new
 [nodejs.org release-post.js script]: https://github.com/nodejs/nodejs.org/blob/master/scripts/release-post.js
+[webchat.freenode.net]: https://webchat.freenode.net/