docs: reword commit convention requirements

CONTRIBUTING.md

@@ -89,15 +89,51 @@ to make reviews and retrospection easy. Use your git commits to provide context
 for the reviewers, and the folks who will be reading the codebase in the months
 and years to come.
 
-Kanister recommends using [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) format:
+We're trying to keep all commits in `master` to follow [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) format.
+See [conventions](#commit-conventions) for more info on types and scopes.
+We are using squash and merge approach to PRs which means that commit descriptions are generated from PR descriptions.
+
+It's recommended to use conventional commits when strarting a PR, but follow-up commits in the PR don't have to follow the convention.
+
+### Submitting Pull Requests
+
+**PR titles should be in following format:**
 
 ```text
 <type>[optional scope]: <description>
+```
 
-[optional body]
+See [conventions](#commit-conventions) for more info on types and scopes.
 
-[optional footer]
-```
+When submitting a pull request, it's important that you communicate your intent,
+by clearly:
+
+1. describing the problem you are trying to solve with links to the relevant
+GitHub issues
+1. describing your solution with links to any design documentation and
+discussion
+1. defining how you test and validate your solution
+1. updating the relevant documentation and examples where appropriate
+
+The pull request template is designed to help you convey this information.
+
+In general, smaller pull requests are easier to review and merge than bigger
+ones. It's always a good idea to collaborate with the maintainers to determine
+how best to break up a big pull request.
+
+Once the maintainers approve your PR, they will label it as `kueue`. The
+`mergify` bot will then squash the commits in your PR, and add it to the merge
+queue. The bot will auto-merge your work when it's ready.
+
+Congratulations! Your pull request has been successfully merged! 👏
+
+Thank you for reading through our contributing guide to ensure your
+contributions are high quality and easy for our community to review and accept. 🤝
+
+Please don't hesitate to reach out to us on [Slack](https://join.slack.com/t/kanisterio/shared_invite/enQtNzg2MDc4NzA0ODY4LTU1NDU2NDZhYjk3YmE5MWNlZWMwYzk1NjNjOGQ3NjAyMjcxMTIyNTE1YzZlMzgwYmIwNWFkNjU0NGFlMzNjNTk). if you
+have any questions about contributing!
+
+### Commit conventions
 
 #### Types:
 
@@ -135,54 +171,3 @@ There can be optional `!` after the type and scope to indicate breaking changes
 #### Description:
 
 Short description of WHAT was changed in the commit. SHOULD start with lowercase. MUST NOT have a `.` at the end.
-
-#### Body:
-
-Body should contain a description of changes and **importantly** reasoning behind the changes,
-it may include links to issues or discussions, but should be sufficient to understand WHY the commit is there.
-
-May also contain some information about WHAT was changes if description did not fit all of it.
-
-#### Footer(optional):
-
-In order to indicate breaking changes in the commit message you can use `BREAKING CHANGES:` footer, listing breaking changes, e.g.
-```
-fix!: here's some fix
-
-fixing something
-
-BREAKING CHANGES: it breaks some thing
-and another thing
-```
-
-### Submitting Pull Requests
-
-**Pull request title should follow [conventional commits](#commit-messages) format**
-
-When submitting a pull request, it's important that you communicate your intent,
-by clearly:
-
-1. describing the problem you are trying to solve with links to the relevant
-GitHub issues
-1. describing your solution with links to any design documentation and
-discussion
-1. defining how you test and validate your solution
-1. updating the relevant documentation and examples where appropriate
-
-The pull request template is designed to help you convey this information.
-
-In general, smaller pull requests are easier to review and merge than bigger
-ones. It's always a good idea to collaborate with the maintainers to determine
-how best to break up a big pull request.
-
-Once the maintainers approve your PR, they will label it as `kueue`. The
-`mergify` bot will then squash the commits in your PR, and add it to the merge
-queue. The bot will auto-merge your work when it's ready.
-
-Congratulations! Your pull request has been successfully merged! 👏
-
-Thank you for reading through our contributing guide to ensure your
-contributions are high quality and easy for our community to review and accept. 🤝
-
-Please don't hesitate to reach out to us on [Slack](https://join.slack.com/t/kanisterio/shared_invite/enQtNzg2MDc4NzA0ODY4LTU1NDU2NDZhYjk3YmE5MWNlZWMwYzk1NjNjOGQ3NjAyMjcxMTIyNTE1YzZlMzgwYmIwNWFkNjU0NGFlMzNjNTk). if you
-have any questions about contributing!