docs: update the general guidelines section

docs/CONTRIBUTING.md

@@ -23,7 +23,7 @@ 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
+## [Guidelines for contributing](docs/content/en/contribute/software/guidelines-for-contributing/_index.md)
 
 * Always fork the repository then clone that fork to your local system
   rather than clone `main` directly.

docs/content/en/contribute/software/_index.md

@@ -11,3 +11,5 @@ but all material here has been reviewed for technical accuracy.
 Keptn software and documentation
 is developed and maintained by the Keptn community.
 We invite you to join us.
+
+## [Guidelines for Contributing](docs/content/en/contribute/software/guidelines-for-contributing/_index.md)

docs/content/en/contribute/software/guidelines-for-contributing/_index.md

@@ -0,0 +1,44 @@
+---
+title: Contributing 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.