diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000000..3584177ffd
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,104 @@
+# Contributing to UnifySDK
+
+## Reporting issues ##
+
+Currently there is no way to report issue in the github project,
+however supported @SiliconLabs customers can report cases individually.
+
+
+## Git Branch naming conventions ##
+
+There is no strong requirement for now, but user are encouraged to
+track their changes by prefixing branch names with meaningful prefixes
+such as "feature" or "bugfix".
+
+If the change refers to existing context id, feel free to add it.
+
+
+## Commit message format ##
+
+Commit message should not exceed 50 characters.
+
+Within your commits, you can include a commit description,
+allowing us to add even more detail / context as to what you did.
+
+Add an empty line underneath the commit message,
+and begin writing a description from line 3.
+
+Example:
+
+```
+Fixes Issue with login button not showing.
+
+- Update login form validation
+- Update login styling for showing the button
+```
+
+
+## Pull request guidelines ##
+
+Pull Request Naming guidelines.
+
+```
+Context: <message clearing explaining what commit does>
+```
+
+Write a useful description in the "details" section of your pull request.
+
+Max size of Pull request should be < 300 lines (excluding autogenerated code)
+
+If Changes are greater than 300 lines,
+try to split the changes into logical groups using multiple PRs.
+
+Pull Request should be raised only after running the existing unit Test cases,
+lint script passed in locally.
+
+One Pull Request should address only one issues
+(don’t combine multiple changes including indentation as well)
+
+Please avoid to change the code while reviewing,
+nd in case of partial code it should mandatory have draft state.
+
+Use "Draft" state for asking developers not to review the code
+or to block merging code.
+
+Pull Request should be ideally closed within 2-3 days of raising the request.
+
+
+### As a Reviewer: ###
+
+What to consider when we are reviewing a Pull Request
+
+Does the code has successful build ?
+
+Does the code follow unify coding guidelines?
+
+Does the code meet its objective / acceptance criteria?
+
+Does the code have unit test and documentation included?
+
+Does the code need any refactoring, considering security,
+performance or simply ease of reading?
+
+Use "Suggestion" feature which allows you to add
+a code suggestion directly into the comment,
+which can instantly be accepted and committed from within the PR.
+
+Write clear comments.
+Describe the issue, why you don’t agree (mistakes, errors, violations against
+conventions, performance risk, security issues, etc.),
+and propose other solutions to simplify and improve the code.
+
+If any of the comments need to be addressed mandatory,
+mark the pull request as Draft.
+
+## Unit tests ##
+
+Build with -DBUILD_TESTING=ON
+
+Then "ninja" and "ninja test" : this command runs all the tests.
+
+If you want to test individually
+you can do by running test executables from shell
+
+Build and unit tests are run from contributor fork using github actions.