chore(pull_request): add pull request template

.github/pull_request_template.md

@@ -0,0 +1,44 @@
+**Purpose of PR?**:
+
+Fixes #
+
+**Does this PR introduce a breaking change?**
+
+**If the changes in this PR are manually verified, list down the scenarios covered:**:
+
+**Additional information for reviewer?** :
+_Mention if this PR is part of any design or a continuation of previous PRs_
+
+
+**Checklist:**
+- [ ] Bug fix. Fixes #<issue number>
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] This change requires a documentation update
+- [ ] PR Title follows the convention of  `<type>(<scope>): <subject>`
+- [ ] Commit has unit tests
+- [ ] Commit has integration tests
+
+<!--
+
+The PR title message must follow convention:
+`<type>(<scope>): <subject>`.
+
+Where: <br />
+- `type` is to define what type of PR is this.
+  Most common types are:
+    - `feat`      - for new features, not a new feature for build script
+    - `fix`       - for bug fixes or improvements, not a fix for build script
+    - `chore`     - changes not related to production code
+    - `docs`      - changes related to documentation
+    - `style`     - formatting, missing semi colons, linting fix etc; no significant production code changes
+    - `test`      - adding missing tests, refactoring tests; no production code change
+    - `refactor`  - refactoring production code, eg. renaming a variable or function name, there should not be any significant production code changes
+
+- `scope` is a single word that best describes where the changes fit.
+    - feature(`monitor`,`enforcer`)
+    - test(`tests`, `bdd`)
+    - chore(`build`)
+- `subject` is a single line brief description of the changes made in the pull request.
+
+-->

.gitignore

@@ -7,6 +7,7 @@ deploygen
 
 # contribution
 .vscode
+.idea
 
 # vagrant
 .vagrant