docs: clarify which commit types trigger a release

README.md

@@ -68,9 +68,9 @@ Here is an example of the release type that will be done based on a commit messa
 
 ### Triggering a release
 
-When pushing new commits to the release branch (i.e. `master`) with `git push` or by merging a pull request or merging from another branch, a CI build is triggered and runs the `semantic-release` command to make a release if there are relevant codebase changes since the last release.
+For each new commits added to the release branch (i.e. `master`) with `git push` or by merging a pull request or merging from another branch, a CI build is triggered and runs the `semantic-release` command to make a release if there are codebase changes since the last release that that affect the package functionalities.
 
-By default a release will be done for each push to the release branch that contains relevant code changes. If you need more control over the timing of releases you have a couple of options:
+If you need more control over the timing of releases you have a couple of options:
 - Publish releases on a distribution channel (for example npm’s [dist-tags](https://docs.npmjs.com/cli/dist-tag)). This way you can keep control over what your users end up using by default, and you can decide when to make an automatically released version available to the stable channel, and promote it.
 - Develop on a `dev` branch and merge it to the release branch (i.e. `master`) once you are ready to publish. **semantic-release** will run only on pushes to the release branch.
 

docs/support/FAQ.md

@@ -164,6 +164,21 @@ You can trigger a release by pushing to your Git repository. You deliberately ca
 
 Yes, every commits that contains `[skip release]` or `[release skip]` in their message will be excluded from the commit analysis and won't participate in the release type determination.
 
+## How can I change the type of commits that trigger a release?
+
+By default **semantic-release** uses the [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines) and triggers releases based on the following rules:
+
+| Commit                      | Release type               |
+|-----------------------------|----------------------------|
+| Commit with breaking change | ~~Major~~ Breaking release |
+| Commit with type `feat`     | ~~Minor~~ Feature release  |
+| Commit with type `fix`      | Patch release              |
+| Commit with type `perf`     | Patch release              |
+
+See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#npm-configuration) plugin documentation for more details.
+
+This is fully customizable with the [`@semantic-release/commit-analyzer`](https://github.com/semantic-release/commit-analyzer) plugin's [`release-rules` option](https://github.com/semantic-release/commit-analyzer#release-rules).
+
 ## Is it *really* a good idea to release on every push?
 
 It is indeed a great idea because it *forces* you to follow best practices. If you don’t feel comfortable releasing every feature or fix on your `master` you might not treat your `master` branch as intended.
@@ -174,6 +189,8 @@ From [Understanding the GitHub Flow](https://guides.github.com/introduction/flow
 
 If you need more control over the timing of releases, see [Triggering a release](../../README.md#triggering-a-release) for different options.
 
+**Note**: Only the codebase changes altering the published package will trigger a release (for example new features, bug fixes or performance improvements would trigger a release while refactoring or changing code style would not). See [How can I change the type of commits that trigger a release?](#how-can-i-change-the-type-of-commits-that-trigger-a-release) for more details.
+
 ## Can I set the initial release version of my package to `0.0.1`?
 
 This is not supported by **semantic-release** as it's not considered a good practice, mostly because [Semantic Versioning](https://semver.org) rules applies differently to major version zero.