Standardize Issue and PR Templates for Better Feature Tracking and Testing

[Dileepadari]

Currently, many issues and pull requests are created without enough context about the feature being introduced. This makes it difficult for contributors and testers to understand:

• Why the feature exists
• What problem it is solving
• What the expected behavior should be
• What exactly needs to be tested

Because of this, testing becomes inconsistent and contributors may not fully understand the intended functionality.

To improve clarity and maintainability, it would be helpful to introduce standardized templates for Issues and Pull Requests.

These templates would ensure that every feature or change clearly includes:

• The motivation behind the change
• The expected behavior
• Steps to test the implementation
• Any relevant screenshots or examples
• Possible edge cases or limitations

This will help:

• Contributors understand the intent of the feature
• Testers know what exactly to verify
• Reviewers quickly evaluate the PR
• Maintain better documentation of decisions

Suggested templates are provided below for discussion and improvement.

---

2. Suggested Issue Template

## Summary
A clear and concise description of the issue.

## Problem / Motivation
Describe the problem this issue addresses.

Questions to consider:
- What is currently happening?
- Why is this a problem?
- Who is affected?

## Current Behaviour
Describe the current behaviour of the system.

## Expected Behaviour
Describe what the correct or desired behaviour should be.

## Steps to Reproduce (For Bugs)

## Proposed Solution (Optional)
If you have ideas for solving this issue, describe them here.

## Screenshots / Logs
Provide screenshots, logs, or recordings if applicable.

## Additional Context
Any other context, references, or links that may help understand this issue.

---

3. Suggested Pull Request Template

## Summary
Short description of the changes made in this PR.

## Related Issue (If any)
Link the issue this PR resolves.

## Related PR (If any)

Fixes #

## Changes Introduced
- Change 1
- Change 2
- Change 3

## Expected Behaviour
Describe what the final behaviour should be after this PR.

## Testing Instructions
Steps reviewers can follow to verify the changes.

## Screenshots / Demo
(Optional)

## Checklist
- [ ] Schema Changed
- [ ] Documentation updated if required