chore: added "feat" to commit message section

.github/CONTRIBUTING.md

@@ -2,6 +2,8 @@
 Thank you for showing interest in contributing to Pretendo Network! As an open source project, Pretendo Network welcomes contributions from developers outside of our core team. We are a large project, made up of over 100 different repositories spanning various languages and scopes. For the sake of consistency and maintainability, we have created these guidelines to outline project goals, standards, and best practices. This document will cover both code contributions as well as going over how to report any bugs or issues with a service or documentation. By adhering to these guidelines, contributors can ensure that their contributions align with the project's vision and meet the quality standards expected by the community.
 
 ### Contents
+- [How to contribute](#how-to-contribute)
+		- [Contents](#contents)
 - [Prerequisites](#prerequisites)
 - [Making Issues](#making-issues)
 - [Code Changes](#code-changes)
@@ -11,6 +13,7 @@ Thank you for showing interest in contributing to Pretendo Network! As an open s
 	- [Scale and Scope](#scale-and-scope)
 	- [Messages](#messages)
 - [Pull Requests](#pull-requests)
+- [Tests](#tests)
 
 # Prerequisites
 Before diving into the contribution process, we recommend familiarizing yourself with our project's existing repositories. By studying our existing codebases, issues, and pull requests you will get a better sense of direction of how we operate. Additionally, please review our [Code of Conduct](CODE_OF_CONDUCT.md) to ensure a respectful and inclusive environment for all participants.
@@ -68,7 +71,7 @@ Besides the changes themselves, commits are the most important part of contribut
 The scale and scope of a commit should be reasonable. Do not commit for every line when making multiple changes, for example. However you should not include many unrelated changes in a single commit. By limiting the scope of the commit we can ensure that if any regressions or new bugs are introduced we can easily revert those changes without the need for major refactors or reimplementations. Limiting the scale of commits also makes review of the changes easier and faster.
 
 ## Messages
-Commit messages should adequately explain the changes in the commit. Messages like "Updated file.md" and "spelling error" should not be used. Nonsense messages such as "oops" or "fixed" are especially not allowed. Commit messages should, at minimum, be in the format `type: message` where `type` represents the type or scope of the changes (`chore`, `docs`, `bug-fix`, etc.) and `message` is the actual changes. Unless the word is from the codebase and starts with a capital letter (such as an exported Go struct), the `message` should be lowercase. We also recommend using both "subject" and "body" commits. This can be achieved through the git CLI by using multiple `-m`/`--message` flags. For example `git commit -m "short subject" -m "longer description of the changes"`.
+Commit messages should adequately explain the changes in the commit. Messages like "Updated file.md" and "spelling error" should not be used. Nonsense messages such as "oops" or "fixed" are especially not allowed. Commit messages should, at minimum, be in the format `type: message` where `type` represents the type or scope of the changes (`feat`, `chore`, `docs`, `bug-fix`, etc.) and `message` is the actual changes. Unless the word is from the codebase and starts with a capital letter (such as an exported Go struct), the `message` should be lowercase. We also recommend using both "subject" and "body" commits. This can be achieved through the git CLI by using multiple `-m`/`--message` flags. For example `git commit -m "short subject" -m "longer description of the changes"`.
 
 The following are examples of good commit messages:
 
@@ -84,6 +87,11 @@ Before making a pull request ensure you have tested all changes and that no regr
 
 Pull requests should never be made against the default (`main`/`master`) branch of a repository. The default branch contains the most recent, stable, version of the codebase. All work on the codebase should take place in other branches. Unless otherwise specified, your target branch should typically be the `dev` branch. You may target other feature branches, however, if need be. If a `dev` branch does not exist for the repository you are working on, please submit a feature request for one to be added before continuing.
 
+A pull request does not necessarily need to *close* an issue. A pull request may be made which implements only a subset of the requirements to close an issue, but does not fully complete the task itself. A pull request should never be *unfinished* code, however. All code must be tested and shippable. A pull request must at minimum bring an issue closer to closing without introducing any new regressions.
+
 Like everything else, pull requests should be as detailed as possible. Your title should adequately summarize the changes being made, and the body of the pull request should fully explain your changes. We ask that, if applicable, the rationale behind your changes also be noted. For example rather than simply "Changed from `for...of` to `forEach`", if the change was made for a performance reason you should say "Changed from `for...of` to `forEach` due to `forEach` being X times faster in this case" and provide some benchmarks. Adding images, videos, etc. is also welcomed in order to illustrate changes. If the changes being made are directly tied to some form of visual (such as a change to the website, a tools GUI, etc.) then images or videos is ***REQUIRED***. If none are provided, then we may delay review until they are given. Providing visual examples of these changes allow us to quickly assess whether or not we wish to proceed with the changes being made.
 
-We ask that you have patience with us as we review your pull request. Pretendo Network only has a single full time developer, all other work is done by volunteers on their own time. Due to the sheer number of issues and pull requests, alongside our other general work and research, it may take us some time to fully review and decide on whether or not to merge your changes.
+We ask that you have patience with us as we review your pull request. Pretendo Network only has a single full time developer, all other work is done by volunteers on their own time. Due to the sheer number of issues and pull requests, alongside our other general work and research, it may take us some time to fully review and decide on whether or not to merge your changes.
+
+# Tests
+We do not require 100% code coverage in any tests. We do not currently have strict rules regarding tests, however we may ask that tests be provided for large or complex changes.

.github/ISSUE_TEMPLATE/enhancement.yaml

@@ -0,0 +1,25 @@
+name: Enhancement
+description: Request an update to an existing feature
+title: "[Enhancement]: "
+labels: ["enhancement", "awaiting-approval"]
+assignees: []
+body:
+  - type: checkboxes
+    attributes:
+      label: Checked Existing
+      description: Ensure you have checked the existing issues, both open and closed, for duplicate issues.
+      options:
+        - label: I have checked the repository for duplicate issues.
+          required: true
+  - type: textarea
+    id: enhancement
+    attributes:
+      label: What enhancement would you like to see?
+    validations:
+      required: true
+  - type: textarea
+    id: other-details
+    attributes:
+      label: Any other details to share? (OPTIONAL)
+    validations:
+      required: false