docs: fix typo and wording

docs/README.md

@@ -27,7 +27,7 @@ the version or a changelog.
 
 - Command-line utility to create commits with your rules. Defaults: [Conventional commits][conventional_commits]
 - Display information about your commit rules (commands: schema, example, info)
-- Bump version automatically using [semantic verisoning][semver] based on the commits. [Read More](./bump.md)
+- Bump version automatically using [semantic versioning][semver] based on the commits. [Read More](./bump.md)
 - Generate a changelog using [Keep a changelog][keepchangelog] (Planned feature)
 
 ## Requirements
@@ -58,7 +58,7 @@ poetry add commitizen --dev
 
 ## Usage
 
-### Commiting
+### Committing
 
 Run in your terminal
 
@@ -106,9 +106,8 @@ commands:
 
 ### Why are `revert` and `chore` valid types in the check pattern of cz conventional_commits but not types we can select?
 
-`revert` and `chore` are added to the "pattern" in `cz check` in order to prevent backward errors, but officially they are not part of conventional commits, we are using the latest [types from Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#type) (they used to but were removed). Using `chore` or `revert` would be part of a different custom rule.
-
-However, you can always create a customized `cz` with those extra types (See [Customization](https://commitizen-tools.github.io/commitizen/customization/).
+`revert` and `chore` are added to the "pattern" in `cz check` in order to prevent backward errors, but officially they are not part of conventional commits, we are using the latest [types from Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#type) (they used to but were removed).
+However, you can create a customized `cz` with those extra types. (See [Customization](https://commitizen-tools.github.io/commitizen/customization/)
 
 See more discussion in issue [#142](https://github.com/commitizen-tools/commitizen/issues/142) and [#36](https://github.com/commitizen-tools/commitizen/issues/36)
 

docs/bump.md

@@ -108,7 +108,7 @@ tag_format = v$minor.$major.$patch$prerelease
 
 The variables must be preceded by a `$` sign.
 
-Suppported variables:
+Supported variables:
 
 | Variable      | Description                                |
 | ------------- | ------------------------------------------ |

docs/check.md

@@ -59,4 +59,4 @@ The `--commit-msg-file` flag is required, not optional.
 Each time you create a commit, automatically, this hook will analyze it.
 If the commit message is invalid, it'll be rejected.
 
-The commit should follow the given commiting rules; otherwise, it won't be accepted.
+The commit should follow the given committing rules; otherwise, it won't be accepted.

docs/config.md

@@ -65,7 +65,7 @@ The extra tab before the square brackets (`]`) at the end is required.
 
 | Variable | Type | Default | Description |
 | -------- | ---- | ------- | ----------- |
-| `name` | `str` | `"cz_conventional_commits"` | Name of the commiting rules to use |
+| `name` | `str` | `"cz_conventional_commits"` | Name of the committing rules to use |
 | `version` | `str` | `None` | Current version. Example: "0.1.2" |
 | `version_files` | `list` | `[ ]` | Files were the version will be updated. A pattern to match a line, can also be specified, separated by `:` [See more](https://commitizen-tools.github.io/commitizen/bump#files) |
 | `tag_format` | `str` | `None` | Format for the git tag, useful for old projects, that use a convention like `"v1.2.1"`. [See more](https://commitizen-tools.github.io/commitizen/bump#tag_format) |

docs/customization.md

@@ -6,7 +6,7 @@ The basic steps are:
 
 1. Inheriting from `BaseCommitizen`
 2. Give a name to your rules.
-3. expose the class at the end of your file assigning it to `discover_this`
+3. Expose the class at the end of your file assigning it to `discover_this`
 4. Create a python package starting with `cz_` using `setup.py`, `poetry`, etc
 
 Check an [example](convcomms) on how to configure `BaseCommitizen`.
@@ -21,7 +21,7 @@ See [commitizen_cz_template](https://github.com/commitizen-tools/commitizen_cz_t
 
 ### Custom commit rules
 
-Create a file starting with `cz_`, for example `cz_jira.py`. This prefix is used to detect the plugin. Same method [flask uses]
+Create a file starting with `cz_`, for example `cz_jira.py`. This prefix is used to detect the plug-in. Same method [flask uses]
 
 Inherit from `BaseCommitizen`, and you must define `questions` and
 `message`. The others are optional.
@@ -73,7 +73,7 @@ class JiraCz(BaseCommitizen):
         return 'We use this because is useful'
 
 
-discover_this = JiraCz  # used by the plugin system
+discover_this = JiraCz  # used by the plug-in system
 ```
 
 The next file required is `setup.py` modified from flask version.
@@ -189,7 +189,7 @@ message = "Do you want to add body message in commit?"
 
 | Parameter | Type | Default | Description |
 | --------- | ---- | ------- | ----------- |
-| `question` | `dict` | `None` | Questions regarding the commit message. Detatiled below. |
+| `question` | `dict` | `None` | Questions regarding the commit message. Detailed below. |
 | `message_template` | `str` | `None` | The template for generating message from the given answers. `message_template` should either follow the [string.Template](https://docs.python.org/3/library/string.html#template-strings) or [Jinja2](https://jinja.palletsprojects.com/en/2.10.x/) formatting specification, and all the variables in this template should be defined in `name` in `questions`. Note that `Jinja2` is not installed by default. If not installed, commitizen will use `string.Template` formatting. |
 | `example` | `str` | `None` | (OPTIONAL) Provide an example to help understand the style. Used by `cz example`. |
 | `schema` | `str` | `None` | (OPTIONAL) Show the schema used. Used by `cz schema`. |

docs/init.md

@@ -1,7 +1,7 @@
 For new projects, it is possible to run `cz init`.
 
 This command will prompt the user for information about the project and will
-configure the selected file type (`pyproject.toml`, `.cz.toml`, etc).
+configure the selected file type (`pyproject.toml`, `.cz.toml`, etc.).
 
 This will help you quickly set up your project with `commitizen`.
 

docs/tutorials/gitlab_ci.md

@@ -38,7 +38,7 @@ The latest step is to create a `deploy key.` To do this, we should create it und
 
 If you have more projects under the same organization, you can reuse the deploy key created before, but you will have to repeat the step where we have created the environment variables (ssh key, email, and username).
 
-tip: If the CI raise some errors, try to unprotect the private key.
+tip: If the CI raise some errors, try to unprotected the private key.
 
 #### Defining GitLab CI Pipeline
 

docs/tutorials/writing_commits.md

@@ -22,7 +22,7 @@ Not to the important part, when writing commits, it's important to think about:
 You may think this is trivial, but it's not. It's important for the reader to
 understand what happened.
 
-### Recomendations
+### Recommendations
 
 - **Keep the message short**: Makes the list of commits more readable (~50 chars).
 - **Talk imperative**: Follow this rule: `If applied, this commit will <commit message>`