Readme.md files got modified

scripts/bench/README.md

@@ -14,17 +14,17 @@ The second command will run all benchmarks but skip the build process. This is u
 The other commands are as follows:
 
 ```bash
-# will compare local repo vs remote merge base repo
+# will compare local repo vs remote merge-base repo
 yarn start
 
-# will compare local repo vs remote merge base repo
+# will compare local repo vs remote merge-base repo
 # this can significantly improve bench times due to no build
 yarn start --skip-build
 
 # will only build and run local repo against benchmarks (no remote values will be shown)
 yarn start --local
 
-# will only build and run remote merge base repo against benchmarks (no local values will be shown)
+# will only build and run remote merge-base repo against benchmarks (no local values will be shown)
 yarn start --remote
 
 # will only build and run remote master repo against benchmarks

scripts/error-codes/README.md

@@ -1,5 +1,5 @@
 The error code system substitutes React's error messages with error IDs to
-provide a better debugging support in production. Check out the blog post
+provide better debugging support in production. Check out the blog post
 [here](https://reactjs.org/blog/2016/07/11/introducing-reacts-error-code-system.html).
 
 - [`codes.json`](https://github.com/facebook/react/blob/master/scripts/error-codes/codes.json)
@@ -8,7 +8,7 @@ provide a better debugging support in production. Check out the blog post
   our documentation. This file is append-only, which means an existing code in
   the file will never be changed/removed.
 - [`extract-errors.js`](https://github.com/facebook/react/blob/master/scripts/error-codes/extract-errors.js)
-  is an node script that traverses our codebase and updates `codes.json`. You
+  is a node script that traverses our codebase and updates `codes.json`. You
   can test it by running `yarn extract-errors`.
 - [`transform-error-messages`](https://github.com/facebook/react/blob/master/scripts/error-codes/transform-error-messages.js)
   is a Babel pass that rewrites error messages to IDs for a production

scripts/print-warnings/README.md

@@ -1 +1 @@
-We use this script to extract all messages from `warning()` calls. They don't get substituted with anything in the source or the build. We only do this so we can have a copy of these messages in our internal repository and can spot accidental changes to them.
+We use this script to extract all messages from `warning()` calls. They don't get substituted with anything in the source or the build. We only do this to have a copy of these messages in our internal repository and can spot accidental changes to them.

scripts/release/README.md

@@ -8,8 +8,8 @@ A typical release goes like this:
    1. The release may also be [**published 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:
-* [`build-release-locally`](#build-release-locally): Build a release locally from the checked out source code.
+The high-level process of creating releases is [documented below](#process). Individual scripts are documented as well:
+* [`build-release-locally`](#build-release-locally): Build a release locally from the checked-out source code.
 * [`prepare-release-from-ci`](#prepare-release-from-ci): Download a pre-built release from CI.
 * [`prepare-release-from-npm`](#prepare-release-from-npm): Prepare an NPM "next" release to be published as a "stable" release.
 * [`publish`](#publish): Publish the downloaded (or prepared) release to NPM.
@@ -22,7 +22,7 @@ If this is your first time running the release scripts, go to the `scripts/relea
 
 ## 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.
+The sections below include meaningful `--tags` in the instructions. However, keep in mind that **the `--tags` arguments are 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.
 
 ## Publishing Next
 
@@ -69,7 +69,7 @@ scripts/release/publish.js --tags experimental
 
 If the OTP code expires while publishing, re-run this command and answer "y" to the questions about whether it was expected for already published packages.
 
-<sup>1: We have plans to make this less awkward. Ideally these releases will be published by a cron job.</sup>
+<sup>1: We have plans to make this less awkward. Ideally, these releases will be published by a cron job.</sup>
 
 ## Publishing a Stable Release
 
@@ -108,13 +108,13 @@ Begin by creating a branch from the previous git tag<sup>1</sup>:
 git checkout -b 16.8.3 v16.8.2
 ```
 
-Next cherry pick any changes from master that you want to include in the release:
+Next cherry-pick any changes from the master that you want to include in the release:
 
 ```sh
 git cherry-pick <commit-hash>
 ```
 
-Once you have cherry picked all of the commits you want to include in the release, push your feature branch and create a Pull Request (so that Circle CI will create a build):
+Once you have cherry-picked all of the commits you want to include in the release, push your feature branch and create a Pull Request (so that Circle CI will create a build):
 
 ```sh
 git push origin 16.8.3