docs: improve documentation templates and quality assurance checklist

.github/ISSUE_TEMPLATE/documentation.yml

@@ -7,7 +7,7 @@ body:
     attributes:
       value: |
         ✰  Thanks for opening an issue! ✰    
-        Tell us where what you would like to see get added to the documentation or if there is an error in the documentation?
+        Please let us know what you would like to see added to the documentation or if you've found any errors in the existing documentation.
 
   - type: textarea
     id: what-happened

.github/ISSUE_TEMPLATE/feature-request.yml

@@ -22,7 +22,7 @@ body:
     attributes:
       label: Problem Definition
       description: |
-        If applicable please answer the below questions
+        If applicable, please answer the below questions:
         Why do we need this feature? 
         What problems may be addressed by introducing this feature?
         What benefits does the SDK stand to gain by including this feature?
@@ -35,7 +35,7 @@ body:
     attributes:
       label: Proposed Feature
       description: |
-        Description of the proposed features or changes to an existing feature to meet your needs
+        Please provide a detailed description of the proposed feature or changes to existing functionality that would meet your needs.
       placeholder: Description of the proposed feature(s)
     validations:
       required: true

.github/ISSUE_TEMPLATE/qa.md

@@ -79,9 +79,14 @@ v                     without deliberation
     * [ ] Make sure state machine logic matches Msg method documentation
     * [ ] Ensure that all state machine edge cases are covered with tests and that test coverage is sufficient (at least 90% coverage on module code)
     * [ ] Assess potential threats for each method including spam attacks and ensure that threats have been addressed sufficiently. This should be done by writing up threat assessment for each method. Specifically we should be paying attention to: 
-        * [ ] algorithmic complexity and places this could be exploited (ex. nested `for` loops)
-        * [ ] charging gas complex computation (ex. `for` loops)
-        * [ ] storage is safe (we don't pollute the state).
+        * [ ] Algorithmic Complexity Audit:
+            * [ ] Identify and review all nested loops and complex computations
+            * [ ] Verify proper gas charging for complex operations
+            * [ ] Check for potential DoS vectors in loops and recursions
+        * [ ] Storage Safety Audit:
+            * [ ] Verify state pollution prevention
+            * [ ] Check proper cleanup of temporary storage
+            * [ ] Review storage access patterns
     * [ ] Assess potential risks of any new third party dependencies and decide whether a dependency audit is needed
     * [ ] Check correctness of simulation implementation if any
 * [ ] Audit Changelog against commit log, ensuring all breaking changes, bug fixes, and improvements are properly documented.