docs: fix typos, markdown table format, and grammar mistakes

Author: bearomorphism

docs/commands/changelog.md

@@ -56,7 +56,7 @@ These are the variables used by the changelog generator.
 It will create a full block like above per version found in the tags.
 And it will create a list of the commits found.
 The `change_type` and the `scope` are optional, they don't need to be provided,
-but if your regex does they will be rendered.
+but if your regex does, they will be rendered.
 
 The format followed by the changelog is the one from [keep a changelog][keepachangelog]
 and the following variables are expected:
@@ -108,7 +108,7 @@ cz bump --changelog
 
 This value can be updated in the `toml` file with the key `changelog_file` under `tools.commitizen`
 
-Specify the name of the output file, remember that changelog only works with markdown.
+Specify the name of the output file, remember that changelog only works with Markdown.
 
 ```bash
 cz changelog --file-name="CHANGES.md"
@@ -120,7 +120,7 @@ This flag can be set in the `toml` file with the key `changelog_incremental` und
 
 Benefits:
 
-- Build from latest version found in changelog, this is useful if you have a different changelog and want to use commitizen
+- Build from the latest version found in changelog, this is useful if you have a different changelog and want to use commitizen
 - Update unreleased area
 - Allows users to manually touch the changelog without being rewritten.
 
@@ -185,8 +185,8 @@ See [the template customization section](../customization.md#customizing-the-cha
 
 Supported hook methods:
 
-- per parsed message: useful to add links
-- end of changelog generation: useful to send slack or chat message, or notify another department
+- Per parsed message: Useful to add links
+- End of changelog generation: Useful to send Slack or chat messages, or notify another department
 
 Read more about hooks in the [customization page][customization]
 

docs/commands/check.md

@@ -2,9 +2,9 @@
 
 ## About
 
-This feature checks whether the commit message follows the given committing rules. And comment in git message will be ignored.
+This feature checks whether the commit message follows the given committing rules. Comments in git messages will be ignored.
 
-If you want to setup an automatic check before every git commit, please refer to
+If you want to set up an automatic check before every git commit, please refer to
 [Automatically check message before commit](../tutorials/auto_check.md).
 
 ## Usage
@@ -27,7 +27,7 @@ $ cz check --rev-range REV_RANGE
 
 For example, if you'd like to check all commits on a branch, you can use `--rev-range master..HEAD`. Or, if you'd like to check all commits starting from when you first implemented commit message linting, you can use `--rev-range <first_commit_sha>..HEAD`.
 
-For more info on how git commit ranges work, you can check the [git documentation](https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection#_commit_ranges).
+For more information on how git commit ranges work, you can check the [git documentation](https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection#_commit_ranges).
 
 ### Commit Message
 
@@ -47,16 +47,16 @@ In this option, MESSAGE is the commit message to be checked.
 $ echo MESSAGE | cz check
 ```
 
-In this option, MESSAGE is piped to cz check and would be checked.
+In this option, MESSAGE is piped to cz check and will be checked.
 
 ### Commit Message File
 
 ```bash
 $ cz check --commit-msg-file COMMIT_MSG_FILE
 ```
 
-In this option, COMMIT_MSG_FILE is the path of the temporal file that contains the commit message.
-This argument can be useful when cooperating with git hook, please check [Automatically check message before commit](../tutorials/auto_check.md) for more information about how to use this argument with git hook.
+In this option, COMMIT_MSG_FILE is the path of the temporary file that contains the commit message.
+This argument can be useful when cooperating with git hooks. Please check [Automatically check message before commit](../tutorials/auto_check.md) for more information about how to use this argument with git hooks.
 
 ### Allow Abort
 
@@ -69,19 +69,19 @@ permit them. Since `git commit` accepts an `--allow-empty-message` flag (primari
 
 ### Allowed Prefixes
 
-If the commit message starts by some specific prefixes, `cz check` returns `True` without checkign the regex.
-By default, the the following prefixes are allowed: `Merge`, `Revert`, `Pull request`, `fixup!` and `squash!`.
+If the commit message starts with some specific prefixes, `cz check` returns `True` without checking the regex.
+By default, the following prefixes are allowed: `Merge`, `Revert`, `Pull request`, `fixup!` and `squash!`.
 
 ```bash
 cz check --message MESSAGE --allowed-prefixes 'Merge' 'Revert' 'Custom Prefix'
 ```
 
 ### Commit message length limit
 
-The argument `-l` (or `--message-length-limmit`) followed by a positive number, can limit the length of commit messages.
+The argument `-l` (or `--message-length-limit`) followed by a positive number can limit the length of commit messages.
 For example, `cz check --message MESSAGE -l 3` would fail the check, since `MESSAGE` is more than 3 characters long.
 By default, the limit is set to 0, which means no limit on the length.
 
-**Note that the limit applies only to the first line of the message.***
+**Note that the limit applies only to the first line of the message.**
 Specifically, for `ConventionalCommitsCz` the length only counts from the type of change to the subject,
-while the body, and the footer are not counted.
+while the body and the footer are not counted.

docs/commands/commit.md

@@ -45,7 +45,7 @@ a new commit message to be prompted.
 The argument `-l` (or `--message-length-limit`) followed by a positive number can limit the length of commit messages.
 An exception would be raised when the message length exceeds the limit.
 For example, `cz commit -l 72` will limit the length of commit messages to 72 characters.
-By default the limit is set to 0, which means no limit on the length.
+By default, the limit is set to 0, which means no limit on the length.
 
 **Note that the limit applies only to the first line of the message.**
 Specifically, for `ConventionalCommitsCz` the length only counts from the type of change to the subject,

docs/config.md

@@ -341,7 +341,7 @@ commitizen:
 ## Version providers
 
 Commitizen can read and write version from different sources.
-By default, it use the `commitizen` one which is using the `version` field from the commitizen settings.
+By default, it uses the `commitizen` one which is using the `version` field from the commitizen settings.
 But you can use any `commitizen.provider` entrypoint as value for `version_provider`.
 
 Commitizen provides some version providers for some well known formats:
@@ -369,9 +369,9 @@ version_provider = "pep621"
 
 ### Custom version provider
 
-You can add you own version provider by extending `VersionProvider` and exposing it on the `commitizen.provider` entrypoint.
+You can add your own version provider by extending `VersionProvider` and exposing it on the `commitizen.provider` entrypoint.
 
-Here a quick example of a `my-provider` provider reading and writing version in a `VERSION` file.
+Here is a quick example of a `my-provider` provider reading and writing version in a `VERSION` file.
 
 ```python title="my_provider.py"
 from pathlib import Path

docs/contributing.md

@@ -8,25 +8,25 @@ If you're a first-time contributor, you can check the issues with [good first is
 
 ## Install before contributing
 
-1. Install [poetry](https://python-poetry.org/) `>=2.0.0`, installation [pages](https://python-poetry.org/docs/#installing-with-the-official-installer)
-2. Install [gpg](https://gnupg.org), installation [pages](https://gnupg.org/documentation/manuals/gnupg/Installation.html#Installation). For Mac users, you could try [homebrew](https://brew.sh/).
+1. Install [poetry](https://python-poetry.org/) `>=2.0.0`. See installation [pages](https://python-poetry.org/docs/#installing-with-the-official-installer).
+2. Install [gpg](https://gnupg.org). See installation [pages](https://gnupg.org/documentation/manuals/gnupg/Installation.html#Installation). For Mac users, you can use [homebrew](https://brew.sh/).
 
 ## Before making a pull request
 
 1. Fork [the repository](https://github.com/commitizen-tools/commitizen).
-2. Clone the repository from your GitHub.
-3. Setup development environment through [poetry](https://python-poetry.org/) (`poetry install`).
-4. Setup [pre-commit](https://pre-commit.com/) hook (`poetry setup-pre-commit`)
-5. Check out a new branch and add your modification.
-6. Add test cases for all your changes.
+1. Clone the repository from your GitHub.
+1. Set up development environment through [poetry](https://python-poetry.org/) (`poetry install`).
+1. Set up [pre-commit](https://pre-commit.com/) hook (`poetry setup-pre-commit`).
+1. Checkout a new branch and add your modifications.
+1. Add test cases for all your changes.
    (We use [CodeCov](https://codecov.io/) to ensure our test coverage does not drop.)
-7. Use [commitizen](https://github.com/commitizen-tools/commitizen) to do git commit. We follow [conventional commits](https://www.conventionalcommits.org/).
-8. Run `poetry all` to ensure you follow the coding style and the tests pass.
-9. Optionally, update the `./docs/README.md` or `docs/images/cli_help` (through running `poetry doc:screenshots`).
-9. **Do not** update the `CHANGELOG.md`, it will be automatically created after merging to `master`.
-10. **Do not** update the versions in the project, they will be automatically updated.
-10. If your changes are about documentation. Run `poetry doc` to serve documentation locally and check whether there is any warning or error.
-11. Send a [pull request](https://github.com/commitizen-tools/commitizen/pulls) 🙏
+1. Use [commitizen](https://github.com/commitizen-tools/commitizen) to do git commit. We follow [conventional commits](https://www.conventionalcommits.org/).
+1. Run `poetry all` to ensure you follow the coding style and the tests pass.
+1. Optionally, update the `./docs/README.md` or `docs/images/cli_help` (through running `poetry doc:screenshots`).
+1. **Do not** update the `CHANGELOG.md`; it will be automatically created after merging to `master`.
+1. **Do not** update the versions in the project; they will be automatically updated.
+1. If your changes are about documentation, run `poetry doc` to serve documentation locally and check whether there are any warnings or errors.
+1. Send a [pull request](https://github.com/commitizen-tools/commitizen/pulls) 🙏
 
 ## Use of GitHub Labels
 
@@ -45,8 +45,8 @@ If you're a first-time contributor, you can check the issues with [good first is
 * pr-status: wait-for-modification
 * pr-status: wait-for-response
 * pr-status: ready-to-merge
-* needs: test-case *(pr only)*
-* needs: documentation *(pr only)*
+* needs: test-case *(PR only)*
+* needs: documentation *(PR only)*
 * type: feature
 * type: bug
 * type: documentation

docs/customization.md

@@ -170,7 +170,7 @@ commitizen:
 
 | Parameter   | Type   | Default | Description                                                                                                                                                                                     |
 | ----------- | ------ | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `type`      | `str`  | `None`  | The type of questions. Valid types: `list`, `select`, `input` and etc. The `select` type provides an interactive searchable list interface. [See More][different-question-types]                  |
+| `type`      | `str`  | `None`  | The type of questions. Valid types: `list`, `select`, `input`, etc. The `select` type provides an interactive searchable list interface. [See More][different-question-types]                  |
 | `name`      | `str`  | `None`  | The key for the value answered by user. It's used in `message_template`                                                                                                                         |
 | `message`   | `str`  | `None`  | Detail description for the question.                                                                                                                                                            |
 | `choices`   | `list` | `None`  | (OPTIONAL) The choices when `type = list` or `type = select`. Either use a list of values or a list of dictionaries with `name` and `value` keys. Keyboard shortcuts can be defined via `key`. See examples above. |
@@ -192,10 +192,10 @@ To specify keyboard shortcuts for your custom choices, provide the shortcut usin
 
 The basic steps are:
 
-1. Inheriting from `BaseCommitizen`
+1. Inheriting from `BaseCommitizen`.
 2. Give a name to your rules.
-3. Create a python package using `setup.py`, `poetry`, etc
-4. Expose the class as a `commitizen.plugin` entrypoint
+3. Create a python package using `setup.py`, `poetry`, etc.
+4. Expose the class as a `commitizen.plugin` entrypoint.
 
 Check an [example][convcomms] on how to configure `BaseCommitizen`.
 
@@ -322,9 +322,9 @@ You can customize it of course, and this are the variables you need to add to yo
 | `commit_parser`                  | `str`                                                                    | NO       | Regex which should provide the variables explained in the [changelog description][changelog-des]                                                                                                                    |
 | `changelog_pattern`              | `str`                                                                    | NO       | Regex to validate the commits, this is useful to skip commits that don't meet your ruling standards like a Merge. Usually the same as bump_pattern                                                                  |
 | `change_type_map`                | `dict`                                                                   | NO       | Convert the title of the change type that will appear in the changelog, if a value is not found, the original will be provided                                                                                      |
-| `changelog_message_builder_hook` | `method: (dict, git.GitCommit) -> dict | list | None`                                  | NO       | Customize with extra information your message output, like adding links, this function is executed per parsed commit. Each GitCommit contains the following attrs: `rev`, `title`, `body`, `author`, `author_email`. Returning a falsy value ignore the commit. |
+| `changelog_message_builder_hook` | `method: (dict, git.GitCommit) -> dict \| list \| None`                  | NO       | Customize with extra information your message output, like adding links, this function is executed per parsed commit. Each GitCommit contains the following attrs: `rev`, `title`, `body`, `author`, `author_email`. Returning a falsy value ignore the commit. |
 | `changelog_hook`                 | `method: (full_changelog: str, partial_changelog: Optional[str]) -> str` | NO       | Receives the whole and partial (if used incremental) changelog. Useful to send slack messages or notify a compliance department. Must return the full_changelog                                                     |
-| `changelog_release_hook` | `method: (release: dict, tag: git.GitTag) -> dict` | NO | Receives each generated changelog release and its associated tag. Useful to enrich a releases before they are rendered. Must return the update release
+| `changelog_release_hook` | `method: (release: dict, tag: git.GitTag) -> dict` | NO | Receives each generated changelog release and its associated tag. Useful to enrich releases before they are rendered. Must return the update release
 
 ```python
 from commitizen.cz.base import BaseCommitizen
@@ -395,7 +395,7 @@ class NoSubjectProvidedException(CzException):
 Commitizen migrated to a new plugin format relying on `importlib.metadata.EntryPoint`.
 Migration should be straight-forward for legacy plugins:
 
-- Remove the `discover_this` line from you plugin module
+- Remove the `discover_this` line from your plugin module
 - Expose the plugin class under as a `commitizen.plugin` entrypoint.
 
 The name of the plugin is now determined by the name of the entrypoint.
@@ -455,12 +455,12 @@ By default, the template used is the `CHANGELOG.md.j2` file from the commitizen
 
 ### Providing a template with your customization class
 
-There is 3 parameters available to change the template rendering from your custom `BaseCommitizen`.
+There are 3 parameters available to change the template rendering from your custom `BaseCommitizen`.
 
 | Parameter         | Type   | Default | Description                                                                                           |
 | ----------------- | ------ | ------- | ----------------------------------------------------------------------------------------------------- |
-| `template`        | `str`  | `None`  | Provide your own template name (default to `CHANGELOG.md.j2`)                            |
-| `template_loader` | `str`  | `None`  | Override the default template loader (so you can provide template from you customization class)       |
+| `template`        | `str`  | `None`  | Provide your own template name (default to `CHANGELOG.md.j2`)                                         |
+| `template_loader` | `str`  | `None`  | Override the default template loader (so you can provide template from your customization class)      |
 | `template_extras` | `dict` | `None`  | Provide some extra template parameters                                                                |
 
 Let's see an example.
@@ -484,14 +484,14 @@ This snippet will:
 
 ### Providing a template from the current working directory
 
-Users can provides their own template from their current working directory (your project root) by:
+Users can provide their own template from their current working directory (your project root) by:
 
 - providing a template with the same name (`CHANGELOG.md.j2` unless overridden by your custom class)
 - setting your template path as `template` configuration
 - giving your template path as `--template` parameter to `bump` and `changelog` commands
 
 !!! Note
-    The path is relative to the current working directory, aka. your project root most of the time.
+    The path is relative to the current working directory, aka your project root most of the time.
 
 ### Template variables
 
@@ -507,7 +507,7 @@ Each `Change` has the following fields:
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
-| scope | `str | None` | An optional scope |
+| scope | `str \| None` | An optional scope |
 | message | `str` | The commit message body |
 | sha1 | `str` | The commit `sha1` |
 | parents | `list[str]` | The parent commit(s) `sha1`(s) |
@@ -524,7 +524,7 @@ When using another template (either provided by a plugin or by yourself), you ca
 by:
 
 - defining them in your configuration with the [`extras` settings][extras-config]
-- providing them on the commandline with the `--extra/-e` parameter to `bump` and `changelog` commands
+- providing them on the command line with the `--extra/-e` parameter to `bump` and `changelog` commands
 
 [template-config]: config.md#template
 [extras-config]: config.md#extras