From f8bd1e8a90710f5c12dc68dfff1848727884d697 Mon Sep 17 00:00:00 2001
From: gravi638 <Gopinath_Ravi@comcast.com>
Date: Tue, 11 Nov 2025 15:15:46 +0530
Subject: [PATCH] Created new pull request template file

---
 CONTRIBUTING.md          | 12 +++++++++++
 pull_request_template.md | 45 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 57 insertions(+)
 create mode 100644 pull_request_template.md

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 5476335..be7ab68 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -3,3 +3,15 @@ Contributing
 If you would like to contribute code to this project you can do so through GitHub by forking the repository
 and sending a pull request.
 Before RDK accepts your code into the project you must sign the RDK Contributor License Agreement (CLA).
+
+### Branch Structure
+- **`main`** - Production-ready code. All releases are tagged from this branch.
+- **`develop`** - Any feature development/bugfixes must first go into this branch and once changes are validated/tested and then raise PR to main branch.
+- All contributors should first raise pull requests against the develop branch after receiving the PR approvals. Once the changes are validated and tested, a cherry-pick to main branch should be performed. This ensures that production remains stable and only verified changes are submitted.
+
+
+### Workflow and Branch Rules
+- **Feature PRs**: Target `develop` branch
+- **Bug fix PRs**: Target `develop` branch (unless critical hotfix)
+- **`main`** - branch is the latest stable release.
+- No direct commit to develop and main branch, instead create a feature or bugfix branch for your changes and submit a pull request (PR).
\ No newline at end of file
diff --git a/pull_request_template.md b/pull_request_template.md
new file mode 100644
index 0000000..f57753d
--- /dev/null
+++ b/pull_request_template.md
@@ -0,0 +1,45 @@
+## Pull Request Guidelines
+
+### PR Title Format
+- Always begin the title with the ticket number
+- Title should succinctly describe the PR purpose
+- Remove this section when you creating a PR
+
+### PR Description Template
+```
+## Summary
+• [Link to ticket](ticket-url)
+• BUG/FEATURE: Brief description of the change
+
+## Details
+• Provide 5-6 lines of details unless the PR is trivial
+• Use bulleted lists for better readability
+• If it's a new feature, this section must be filled out
+• Include technical approach and implementation notes
+• Mention any breaking changes or migration steps
+
+## Checklist
+PR Reviewers should ensure this section is completed:
+- [ ] is Unit tests included
+- [ ] Code coverage from unit tests before this PR: _%
+- [ ] Code coverage from unit tests after this PR: _%
+- [ ] Does this change the db schema? If yes, flag for review
+```
+
+### Requirements Before Creating PR
+- Ensure your branch is up-to-date with target branch
+- Run all tests locally: `make test`
+- Write/update tests for your changes
+- Code coverage should not decrease significantly
+
+## Code Standards
+- Follow standard Go conventions and use `gofmt`
+- Add comments for exported functions and complex logic
+- Handle errors appropriately
+- Use meaningful variable and function names
+
+## Review Process
+- **For `develop` branch**: At least 1 approval from maintainer
+- **For `main` branch**: At least 2 approvals from maintainers
+- All CI checks must pass including CLA verification
+- Code coverage must be maintained