docs: refactor contributing guide - general guidelines

docs/CONTRIBUTING.md

@@ -23,41 +23,9 @@ If you need help getting started,
 feel free to ask for help on the `#help-contributing` or `#keptn-docs` channels on the [Keptn Slack](https://keptn.sh/community/#slack).
 We were all new to this once and are happy to help you!
 
-## Guidelines for contributing
-
-* Always fork the repository then clone that fork to your local system
-  rather than clone `main` directly.
-  Keptn, like most open source projects,
-  severely restricts who can push changes directly to the `main` branch
-  to protect the integrity of the repository.
-* Keep your language clean and crisp.
-* Smaller PR's are easier to review and so generally get processed more quickly;
-  when possible, chunk your work into smallish PR's.
-  However, we recognize that documentation work sometimes requires larger PRs,
-  such as when writing a whole new section or reorganizing existing files.
-* You may want to squash your commits before creating the final PR,
-  to avoid conflicting commits.
-  This is **not mandatory**; the maintainers will squash your commits
-  during the merge when necessary.
-* Be sure that the description of the pull request itself
-  is meaningful and clear.
-  This helps reviewers understand each commit
-  and provides a good history after the PR is merged.
-* If your PR is not reviewed in a timely fashion,
-  feel free to post a gentle reminder to the `#keptn-docs` Slack channel.
-* Resolve review comments and suggestions promptly.
-
-If you see a problem and are unable to fix it yourself
-or have an idea for an enhancement,
-please create an issue on the GitHub repository:
-
-* Provide specific and detailed information about the problem
-  and possible solutions to help others understand the issue.
-* When reporting a bug, provide a detailed list of steps to reproduce the bug.
-  If possible, also attach screenshots that illustrate the bug.
-* If you want to do the work on an issue,
-  include that information in your description of the issue
-  or in a comment to the issue.
+## Guidelines for Contributing
+
+Please check [Contribution Guidelines](content/en/contribute/docs/contribution-guidelines/_index.md).
 
 ## Building the documentation locally
 

docs/content/en/contribute/docs/contribution-guidelines/_index.md

@@ -0,0 +1,46 @@
+---
+title: Contribution Guidelines
+description: Guidelines for contributing towards Keptn Lifecycle Toolkit
+weight: 300
+---
+
+Before using the **Keptn Lifecycle Toolkit**
+as a contributor to the Kepth Lifecycle Toolkit repository,
+it is expected that you comply with the guidelines while
+making contributions towards the repository.
+
+## Guidelines for contributing
+
+* Always fork the repository then clone that fork to your local system
+  rather than clone `main` directly.
+  Keptn, like most open source projects,
+  severely restricts who can push changes directly to the `main` branch
+  to protect the integrity of the repository.
+* Keep your language clean and crisp.
+* Smaller PR's are easier to review and so generally get processed more quickly;
+  when possible, chunk your work into smallish PR's.
+  However, we recognize that documentation work sometimes requires larger PRs,
+  such as when writing a whole new section or reorganizing existing files.
+* You may want to squash your commits before creating the final PR,
+  to avoid conflicting commits.
+  This is **not mandatory**; the maintainers will squash your commits
+  during the merge when necessary.
+* Be sure that the description of the pull request itself
+  is meaningful and clear.
+  This helps reviewers understand each commit
+  and provides a good history after the PR is merged.
+* If your PR is not reviewed in a timely fashion,
+  feel free to post a gentle reminder to the `#keptn-docs` Slack channel.
+* Resolve review comments and suggestions promptly.
+
+If you see a problem and are unable to fix it yourself
+or have an idea for an enhancement,
+please create an issue on the GitHub repository.
+
+* Provide specific and detailed information about the problem
+  and possible solutions to help others understand the issue.
+* When reporting a bug, provide a detailed list of steps to reproduce the bug.
+  If possible, also attach screenshots that illustrate the bug.
+* If you want to do the work on an issue,
+  include that information in your description of the issue
+  or in a comment to the issue.