chore: Update CONTRIBUTING.md (#501)

* Update CONTRIBUTING.md

Signed-off-by: Sukriti Sharma <[email protected]>

* Update CONTRIBUTING.md

Co-authored-by: Dushyant Behl <[email protected]>
Signed-off-by: Sukriti Sharma <[email protected]>

* Update CONTRIBUTING.md

Co-authored-by: Dushyant Behl <[email protected]>
Signed-off-by: Sukriti Sharma <[email protected]>

* Update CONTRIBUTING.md

Co-authored-by: Will Johnson <[email protected]>
Signed-off-by: Sukriti Sharma <[email protected]>

* Update CONTRIBUTING.md

Co-authored-by: Dushyant Behl <[email protected]>
Signed-off-by: Sukriti Sharma <[email protected]>

* Update CONTRIBUTING.md

Signed-off-by: Sukriti Sharma <[email protected]>

---------

Signed-off-by: Sukriti Sharma <[email protected]>
Co-authored-by: Dushyant Behl <[email protected]>
Co-authored-by: Will Johnson <[email protected]>

Author: 3 people

CONTRIBUTING.md

@@ -30,8 +30,11 @@ To contribute to this repo, you'll use the Fork and Pull model common in many op
 Guide](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)
 from Kubernetes.
 
-When your contribution is ready, you can create a pull request. Pull requests are often referred to as "PR". In general, we follow the standard [GitHub pull request](https://help.github.com/en/articles/about-pull-requests) process. Follow the template to provide details about your pull request to the maintainers. It's best to break your contribution into smaller PRs with incremental changes, and include a good description of the changes. 
-We require new unit tests to be contributed with any new functionality added. 
+When your contribution is ready, you can create a pull request. Pull requests are often referred to as "PR". In general, we follow the standard [GitHub pull request](https://help.github.com/en/articles/about-pull-requests) process. Follow the template to provide details about your pull request to the maintainers. 
+1. It's best to break your contribution into smaller PRs with incremental changes, and include a good description of the changes in the PR description. 
+2. We require new unit tests to be contributed with any new functionality added.
+3. We require each feature to be documented as part of the PR. If certain feature is experimental and not documented it will be announced as a dev preview.
+4. We require any new unit tests that are gated by conditions such as package availability must be executed, and details of those along with a screenshot of the test results should be included in the PR description.
 
 Before sending pull requests, make sure your changes pass formatting, linting and unit tests. These checks will run with the pull request builds. Alternatively, you can run the checks manually on your local machine [as specified below](#development).
 
@@ -50,6 +53,8 @@ Once you've [created a pull request](#how-can-i-contribute), maintainers will re
 - Follow the project coding conventions
 - Write detailed commit messages
 - Break large changes into a logical series of smaller patches, which are easy to understand individually and combine to solve a broader issue
+- Ensure documentation is added on `how to use` any new capabilities.
+- Ensure follow-up issues are created for documentation and that feature is not officially released without full documentation.
 
 Maintainers will perform "squash and merge" actions on PRs in this repo, so it doesn't matter how many commits your PR has, as they will end up being a single commit after merging.