From 74b3e8ca6a5cebf71170db9bab48a08375834b89 Mon Sep 17 00:00:00 2001
From: gravi21 <Gopinath_Ravi@comcast.com>
Date: Fri, 10 Oct 2025 15:57:34 +0530
Subject: [PATCH 1/2] PR Contribution Guidelines

---
 CONTRIBUTING.md | 69 +++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 64 insertions(+), 5 deletions(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 5476335..9a632f8 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,5 +1,64 @@
-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).
+Contributing to xconfadmin
+==========================
+
+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 Management
+
+### Branch Structure
+- **`main`** - Production-ready code. All releases are tagged from this branch.
+- **`develop`** - Integration branch for new features. All feature development should be based on this branch.
+
+
+### Workflow and Branch Rules
+- **Feature PRs**: Target `develop` branch
+- **Bug fix PRs**: Target `develop` branch (unless critical hotfix)
+- No direct commit to develop and main branch,create a feature or bugfix branch for your changes and submit a pull request (PR) to merge into the develop or main branches as appropriate."
+
+## 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

From e5714dc169af20e6de363ff7abf2d98edb16058e Mon Sep 17 00:00:00 2001
From: gravi21 <Gopinath_Ravi@comcast.com>
Date: Thu, 16 Oct 2025 15:23:17 +0530
Subject: [PATCH 2/2] Addressed review comments

---
 CONTRIBUTING.md | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 9a632f8..a7d3eca 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -9,13 +9,15 @@ If you would like to contribute code to this project you can do so through GitHu
 
 ### Branch Structure
 - **`main`** - Production-ready code. All releases are tagged from this branch.
-- **`develop`** - Integration branch for new features. All feature development should be based on 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)
-- No direct commit to develop and main branch,create a feature or bugfix branch for your changes and submit a pull request (PR) to merge into the develop or main branches as appropriate."
+- **`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).
 
 ## Pull Request Guidelines