diff --git a/contributors-guide/standards/creating-new-features.md b/contributors-guide/standards/creating-new-features.md
index 21e009b0a..a5a3ea3af 100644
--- a/contributors-guide/standards/creating-new-features.md
+++ b/contributors-guide/standards/creating-new-features.md
@@ -31,7 +31,7 @@ Create a new branch from the `master` branch with the following format: `<branch
 
 1. Create and checkout the branch: `git checkout -b <branchType>/<issue#><issueDescription>` 
 2. Push the branch to your remote: `git push origin <branchType>/<issue#><issueDescription>`
-
+ 
 Where `<branchType>` can be one of the following:
 
 | branchType | Description |
@@ -41,6 +41,23 @@ Where `<branchType>` can be one of the following:
 | release | A release branch containing a snapshot of a release. |
 | backup | A temporary backup branch. Used normally during repo maintenance. |
 
-### Merge into Mojaloop Repo
+### Open a Pull Request (PR)
+
+Once your feature is ready for review, create a Pull Request from you feature branch back into the `master` branch on the Mojaloop Repository. If you're new to GitHub or Pull Requests, take a look at [this guide](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) for more information.
+
+#### Pull Request Titles
+
+Mojaloop uses [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) to help our automated tooling manage releases and deployments. Your Pull Request title _must_conform to the conventional commits specification to pass the CI/CD checks in CircleCI.
+
+By adopting Conventional Commits + Semantic Versioning we can automatically release a new version for a given component and increment the `MAJOR`, `MINOR` and `BUGFIX` versions based soley on the PR titles, and auto generate rich changelogs. (See [this example](https://github.com/mojaloop/thirdparty-scheme-adapter/releases/tag/v11.20.0) of an auto generated changelog)
+
+> **Note**:  
+> When merging (and squashing) a PR, GitHub uses the _title_ of the PR for the git commit message. This means that to specify a breaking change, you must use the `!` format:  
+> "If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change."
+
+**Examples of good PR titles**
+- feat(api): add ability to handle `PUT /thirdpartyRequests/trasactions/{ID}` endpoint
+- fix: update outdated node modules
+- feat(models)!: change database schema
+- chore: tidy up readme
 
-Once the feature is completed create a PR from your Feature Branch into the `master` branch on the Mojaloop repository \(not your personal repo\) for approval, and check validations \(e.g. unit tests, code coverage, etc executed via CircieCI\).