Update release documentation

scripts/release/README.md

@@ -1,11 +1,27 @@
 # React Release Scripts
 
+This document describes how to prepare and publish a release manually, using the command line.
+
+However, most of our releases are actually *prereleases* that get continuously shipped via CI. Our automated prerelease channels are preferred whenever possible, because if they accidentally break, it won't affect production users.
+
+Before proceeding, consider your motivation:
+
+- **"I want to share experimental features with collaborators."** After your code lands in GitHub (behind an experimental feature flag), it will be automatically published via CI within the next weekday. So usually, all you have to do is wait.
+- **"But I want to publish it now!"** You can [trigger the CI job to run automatically](#trigger-an-automated-prerelease).
+- **"I want to publish a stable release with a real version number"** Refer to the ["Publishing a Stable Release"]((#publishing-a-stable-release)) section. If this is your first time running a stable release, consult with another team member before proceeding.
+- **"I have some special use case that's not explicitly mentioned here."** Read the rest of this document, and consult with another team member before proceeding.
+
+# Process
+
+If this is your first time running the release scripts, go to the `scripts/release` directory and run `yarn` to install the dependencies.
+
 The release process consists of several phases, each one represented by one of the scripts below.
 
-A typical release goes like this:
+A typical release cycle goes like this:
 1. When a commit is pushed to the React repo, [Circle CI](https://circleci.com/gh/facebook/react/) will build all release bundles and run unit tests against both the source code and the built bundles.
-2. The release is then [**published to the `next` channel**](#publishing-release) using the [`prepare-release-from-ci`](#prepare-release-from-ci) and [`publish`](#publish) scripts. (Currently this process is manual but might be automated in the future using [GitHub "actions"](https://github.com/features/actions).)
-   1. The release may also be [**published to the `experimental` channel**](#publishing-an-experimental-release) using the the same scripts (but different build artifacts).
+2. Each weekday, an automated CI cron job publishes prereleases to the `next` and `experimental` channels, from tip of the main branch.
+   1. You can also [trigger an automated prerelease via the command line](#trigger-an-automated-prerelease), instead of waiting until the next time the cron job runs.
+   2. For advanced cases, you can [**manually prepare and publish to the `next` channel**](#publishing-release) using the [`prepare-release-from-ci`](#prepare-release-from-ci) and [`publish`](#publish) scripts; or to the [**`experimental` channel**](#publishing-an-experimental-release) using the the same scripts (but different build artifacts).
 3. Finally, a "next" release can be [**promoted to stable**](#publishing-a-stable-release)<sup>1</sup> using the [`prepare-release-from-npm`](#prepare-release-from-npm) and [`publish`](#publish) scripts. (This process is always manual.)
 
 The high level process of creating releases is [documented below](#process). Individual scripts are documented as well:
@@ -16,10 +32,15 @@ The high level process of creating releases is [documented below](#process). Ind
 
 <sup>1. [**Creating a patch release**](#creating-a-patch-release) has a slightly different process than a major/minor release.</sup>
 
-# Process
+## Trigger an Automated Prerelease
 
-If this is your first time running the release scripts, go to the `scripts/release` directory and run `yarn` to install the dependencies.
+If your code lands in the main branch, it will be automaticaly published to the prerelease channels within the next weekday. However, if you want to immediately publish a prerelease, you can trigger the job to run immediately:
+
+```sh
+yarn publish-prereleases
+```
 
+This will grab the most recent revision on the main branch and publish it to the Next and Experimental channels.
 ## Publishing Without Tags
 
 The sections below include meaningful `--tags` in the instructions. However, keep in mind that **the `--tags` arguments is optional**, and you can omit it if you don't want to tag the release on npm at all. This can be useful when preparing breaking changes.