doc: add build wg info to releases.md · nodejs/node@13fd09b

- 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

_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/