docs: fix grammar and typos in README, CONTRIBUTING, installation gui…

…de, and plugin guide

CONTRIBUTING.md

@@ -58,7 +58,7 @@ Good pull requests, whether patches, improvements, or new features, are a fantas
 
 **Please ask first** before embarking on any significant pull requests (e.g. implementing features, refactoring code), otherwise you risk spending a lot of time working on something that the project's developers might not want to merge into the project.
 
-If you never created a pull request before, welcome 🎉 😄. [Here is a great tutorial](https://opensource.guide/how-to-contribute/#opening-a-pull-request) on how to send one :)
+If you have never created a pull request before, welcome 🎉 😄. [Here is a great tutorial](https://opensource.guide/how-to-contribute/#opening-a-pull-request) on how to send one :)
 
 Here is a summary of the steps to follow:
 
@@ -83,15 +83,15 @@ $ git push origin <topic-branch-name>
 
 **Tips**:
 - For ambitious tasks, open a Pull Request as soon as possible with the `[WIP]` prefix in the title, in order to get feedback and help from the community.
-- [Allow semantic-release maintainers to make changes to you Pull Request branch](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork). This way, we can rebase it and make some minor changes if necessary. All changes we make will be done in new commit and we'll ask for your approval before merging them.
+- [Allow semantic-release maintainers to make changes to your Pull Request branch](https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork). This way, we can rebase it and make some minor changes if necessary. All changes we make will be done in new commit and we'll ask for your approval before merging them.
 
 ## Coding rules
 
 ### Source code
 
 To ensure consistency and quality throughout the source code, all code modifications must have:
 - No [linting](#lint) errors
-- A [test](#tests) for every possible cases introduced by your code change
+- A [test](#tests) for every possible case introduced by your code change
 - **100%** test coverage
 - [Valid commit message(s)](#commit-message-guidelines)
 - Documentation for new features
@@ -102,7 +102,7 @@ To ensure consistency and quality throughout the source code, all code modificat
 To ensure consistency and quality, all documentation modifications must:
 - Refer to brand in [bold](https://help.github.com/articles/basic-writing-and-formatting-syntax/#styling-text) with proper capitalization, i.e. **GitHub**, **semantic-release**, **npm**
 - Prefer [tables](https://help.github.com/articles/organizing-information-with-tables) over [lists](https://help.github.com/articles/basic-writing-and-formatting-syntax/#lists) when listing key values, i.e. List of options with their description
-- Use [links](https://help.github.com/articles/basic-writing-and-formatting-syntax/#links) when, the first you are referring to:
+- Use [links](https://help.github.com/articles/basic-writing-and-formatting-syntax/#links) when you are referring to:
   - a **semantic-release** concept described somewhere else in the documentation, i.e. How to [contribute](CONTRIBUTING.md)
   - a third-party product/brand/service, i.e. Integrate with [GitHub](https://github.com)
   - an external concept or feature, i.e. Create a [GitHub release](https://help.github.com/articles/creating-releases)
@@ -125,7 +125,7 @@ If possible, make [atomic commits](https://en.wikipedia.org/wiki/Atomic_commit),
 - a functional change should be contained in exactly one commit
 - a commit should not create an inconsistent state (such as test errors, linting errors, partial fix, feature with documentation etc...)
 
-A complex feature can be broken down into multiple commits as long as each one keep a consistent state and consist of a self-contained change.
+A complex feature can be broken down into multiple commits as long as each one maintains a consistent state and consists of a self-contained change.
 
 #### Commit message format
 
@@ -219,13 +219,13 @@ $ npm install
 
 ### Lint
 
-All the [semantic-release](https://github.com/semantic-release) repository use [XO](https://github.com/sindresorhus/xo) for linting and [Prettier](https://prettier.io) for formatting. Prettier formatting will be automatically verified and fixed by XO.
+All the [semantic-release](https://github.com/semantic-release) repositories use [XO](https://github.com/sindresorhus/xo) for linting and [Prettier](https://prettier.io) for formatting. Prettier formatting will be automatically verified and fixed by XO.
 
-Before pushing your code changes make sure there is no linting errors with `npm run lint`.
+Before pushing your code changes make sure there are no linting errors with `npm run lint`.
 
 **Tips**:
 - Most linting errors can be automatically fixed with `npm run lint --fix`.
-- Install the [XO plugin](https://github.com/sindresorhus/xo#editor-plugins) for your editor to see linting error directly in your editor and automatically fix them on save.
+- Install the [XO plugin](https://github.com/sindresorhus/xo#editor-plugins) for your editor to see linting errors directly in your editor and automatically fix them on save.
 
 ### Tests
 
@@ -246,6 +246,6 @@ $ npm run test
 
 ### Commits
 
-All the [semantic-release](https://github.com/semantic-release) repository use [Commitizen](https://github.com/commitizen/cz-cli) to help you create [valid commit messages](#commit-message-guidelines).
+All the [semantic-release](https://github.com/semantic-release) repositories use [Commitizen](https://github.com/commitizen/cz-cli) to help you create [valid commit messages](#commit-message-guidelines).
 
 After staging your changes with `git add`, run `npm run cm` to start the interactive commit message CLI.

README.md

@@ -48,11 +48,11 @@ This removes the immediate connection between human emotions and version numbers
 
 ### Commit message format
 
-**semantic-release** uses the commit messages to determine the type of changes in the codebase. Following formalized conventions for commit messages, **semantic-release** automatically determines the next [semantic version](https://semver.org) number, generates a changelog and publish the release.
+**semantic-release** uses the commit messages to determine the type of changes in the codebase. Following formalized conventions for commit messages, **semantic-release** automatically determines the next [semantic version](https://semver.org) number, generates a changelog and publishes the release.
 
 By default **semantic-release** uses [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines). The commit message format can be changed with the [`preset` or `config` options](docs/usage/configuration.md#options) of the [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer#options) and [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator#options) plugins.
 
-Tools such as [commitizen](https://github.com/commitizen/cz-cli), [commitlint](https://github.com/marionebl/commitlint) or [semantic-git-commit-cli](https://github.com/JPeer264/node-semantic-git-commit-cli) can be used to help contributor and enforce valid commits message.
+Tools such as [commitizen](https://github.com/commitizen/cz-cli), [commitlint](https://github.com/marionebl/commitlint) or [semantic-git-commit-cli](https://github.com/JPeer264/node-semantic-git-commit-cli) can be used to help contributor and enforce valid commit messages.
 
 Here is an example of the release type that will be done based on a commit messages:
 
@@ -82,12 +82,12 @@ After running the tests the command `semantic-release` will execute the followin
 |-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | Verify Conditions | Verify all the conditions to proceed with the release with the [verify conditions plugins](docs/usage/plugins.md#verifyconditions-plugin).                            |
 | Get last release  | Obtain the commit corresponding to the last release by analyzing [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging).                                       |
-| Analyze commits   | Determine the type of release to do with the [analyze commits plugin](docs/usage/plugins.md#analyzecommits-plugin) based on the commits added since the last release. |
-| Verify release    | Verify the release conformity with the [verify release plugins](docs/usage/plugins.md#verifyrelease-plugin).                                                          |
+| Analyze commits   | Determine the type of release with the [analyze commits plugin](docs/usage/plugins.md#analyzecommits-plugin) based on the commits added since the last release.       |
+| Verify release    | Verify the release conformity with the [verify release plugins](docs/usage/plugins.md#verifyrelease-plugin).                                                           |
 | Generate notes    | Generate release notes with the [generate notes plugin](docs/usage/plugins.md#generatenotes-plugin) for the commits added since the last release.                     |
-| Create Git tag    | Create a Git tag corresponding the new release version                                                                                                                |
-| Prepare           | Prepare the release with the [prepare plugins](docs/usage/plugins.md#prepare-plugin).                                                                                 |
-| Publish           | Publish the release with the [publish plugins](docs/usage/plugins.md#publish-plugin).                                                                                 |
+| Create Git tag    | Create a Git tag corresponding to the new release version                                                                                                             |
+| Prepare           | Prepare the release with the [prepare plugins](docs/usage/plugins.md#prepare-plugin).                                                                                  |
+| Publish           | Publish the release with the [publish plugins](docs/usage/plugins.md#publish-plugin).                                                                                  |
 | Notify            | Notify of new releases or errors with the [success](docs/usage/plugins.md#success-plugin) and [fail](docs/usage/plugins.md#fail-plugin) plugins.                      |
 
 ## Documentation

docs/usage/installation.md

@@ -2,7 +2,7 @@
 
 ## Local installation
 
-For [Node modules projects](https://docs.npmjs.com/getting-started/creating-node-modules) we recommend to install **semantic-release** locally and to run the `semantic-release` command with [npx](https://www.npmjs.com/package/npx):
+For [Node modules projects](https://docs.npmjs.com/getting-started/creating-node-modules) we recommend installing **semantic-release** locally and running the `semantic-release` command with [npx](https://www.npmjs.com/package/npx):
 
 ```bash
 $ npm install --save-dev semantic-release
@@ -14,16 +14,16 @@ Then in the CI environment:
 $ npx semantic-release
 ```
 
-**Note:**: `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently find the semantic-release binary and to execute it. See [What is npx](../support/FAQ.md#what-is-npx) for more details.
+**Note:** `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently find the semantic-release binary and to execute it. See [What is npx](../support/FAQ.md#what-is-npx) for more details.
 
 ## Global installation
 
-For other type of projects we recommend to install **semantic-release** directly in the CI environment, also with [npx](https://www.npmjs.com/package/npx):
+For other type of projects we recommend installing **semantic-release** directly in the CI environment, also with [npx](https://www.npmjs.com/package/npx):
 
 ```bash
 $ npx semantic-release
 ```
 
-**Note:**: For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with with `npx semantic-release@12`, or `npm install -g semantic-release@12`). This way your build will not automatically use the next major **semantic-release** release that could possibly break your build. You will have to upgrade manually when a new major version is released.
+**Note:** For a global installation, it's recommended to specify the major **semantic-release** version to install (for example with with `npx semantic-release@12`, or `npm install -g semantic-release@12`). This way your build will not automatically use the next major **semantic-release** release that could possibly break your build. You will have to upgrade manually when a new major version is released.
 
-**Note:**: `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently install the semantic-release binary and to execute it. See [What is npx](../support/FAQ.md#what-is-npx) for more details.
+**Note:** `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently install the semantic-release binary and to execute it. See [What is npx](../support/FAQ.md#what-is-npx) for more details.

docs/usage/plugins.md

@@ -1,64 +1,64 @@
 # Plugins
 
-Each [release steps](../../README.md#release-steps) is implemented within a plugin or a list of plugins that can be configured, allowing to support different [commit message format](../../README.md#commit-message-format), release not generator and publishing platforms.
+Each [release step](../../README.md#release-steps) is implemented within a plugin or a list of plugins that can be configured. This allows for support of different [commit message formats](../../README.md#commit-message-format), release note generators and publishing platforms.
 
 ## Plugin types
 
 ### verifyConditions plugin
 
-Plugin responsible for verifying all the conditions to proceed with the release: configuration is correct, authentication token are valid, etc...
+Responsible for verifying conditions necessary to proceed with the release: configuration is correct, authentication token are valid, etc...
 
 Default implementation: [npm](https://github.com/semantic-release/npm#verifyconditions) and [github](https://github.com/semantic-release/github#verifyconditions).
 
 ### analyzeCommits plugin
 
-Plugin responsible for determining the type of the next release (`major`, `minor` or `patch`).
+Responsible for determining the type of the next release (`major`, `minor` or `patch`).
 
 Default implementation: [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer).
 
 ### verifyRelease plugin
 
-Plugin responsible for verifying the parameters (version, type, dist-tag etc...) of the release that is about to be published match certain expectations. For example the [cracks plugin](https://github.com/semantic-release/cracks) allows to verify that if a release contains breaking changes, its type must be `major`.
+Responsible for verifying the parameters (version, type, dist-tag etc...) of the release that is about to be published match certain expectations. For example the [cracks plugin](https://github.com/semantic-release/cracks) is able to verify that if a release contains breaking changes, its type must be `major`.
 
 Default implementation: none.
 
 ### generateNotes plugin
 
-Plugin responsible for generating release notes.
+Responsible for generating release notes.
 
 Default implementation: [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator).
 
 ### prepare plugin
 
-Plugin responsible for preparing the release, including:
+Responsible for preparing the release, including:
 - Creating or updating files such as `package.json`, `CHANGELOG.md`, documentation or compiled assets.
 - Create and push commits
 
 Default implementation: [npm](https://github.com/semantic-release/npm#prepare).
 
 ### publish plugin
 
-Plugin responsible for publishing the release.
+Responsible for publishing the release.
 
 Default implementation: [npm](https://github.com/semantic-release/npm#publish) and [github](https://github.com/semantic-release/github#publish).
 
 ### success plugin
 
-Plugin responsible for notifying of a new release.
+Responsible for notifying of a new release.
 
 Default implementation: [github](https://github.com/semantic-release/github#success).
 
 ### fail plugin
 
-Plugin responsible for notifying of a failed release.
+Responsible for notifying of a failed release.
 
 Default implementation: [github](https://github.com/semantic-release/github#fail).
 
 ## Configuration
 
 Plugin can be configured by specifying the plugin's module name or file path directly as a `String` or within the `path` key of an `Object`.
 
-Plugins specific options can be set similarly to the other **semantic-release** [options](configuration.md#options) or within the plugin `Object`. Plugins options defined along the other **semantic-release** [options](configuration.md#options) will apply to all plugins, while the one defined within the plugin `Object` will apply only to this specific plugin.
+Plugins specific options can be set similarly to the other **semantic-release** [options](configuration.md#options) or within the plugin `Object`. Plugins options defined along with the other **semantic-release** [options](configuration.md#options) will apply to all plugins. Options defined within the plugin `Object` will apply to that specific plugin.
 
 For example:
 ```json