kyverno
diff --git a/‎website/docs/community/contribute.md
+150 b/‎website/docs/community/contribute.md
+150
diff --git a/‎website/docs/community/making-a-pull-request.md
+111 b/‎website/docs/community/making-a-pull-request.md
+111
@@ -0,0 +1,150 @@
+# Contributing
+
+Chainsaw, developed by Kyverno, is an advanced end-to-end testing tool for Kubernetes. Our community plays a crucial role in shaping the project by reporting bugs, suggesting features, and improving documentation.
+
+We aim to make our issue tracker, discussion board, and documentation well-structured and easy to navigate. By following our guidelines, you can help us address your requests efficiently.
+
+## How you can contribute
+
+We appreciate your efforts in reporting bugs, requesting features, and engaging in discussions. Here's how you can contribute:
+
+### Creating an issue
+
+<div class="grid cards" markdown>
+
+-   :material-bug-outline: &nbsp;
+    **Something is not working?**
+
+    ---
+
+    Report a bug in Chainsaw by creating an issue with a reproduction
+
+    ---
+
+    [:octicons-arrow-right-24: Report a bug][report a bug]
+
+-   :material-file-document-remove-outline: &nbsp;
+    **Missing information in our docs?**
+
+    ---
+
+    Report missing information or potential inconsistencies in our documentation
+
+    ---
+
+    [:octicons-arrow-right-24: Report a docs issue][report a docs issue]
+
+-   :material-lightbulb-on-20: &nbsp;
+    **Want to submit an idea?**
+
+    ---
+
+    Propose a change, feature request, or suggest an improvement
+
+    ---
+
+    [:octicons-arrow-right-24: Request a change][request a change]
+
+-   :material-account-question-outline: &nbsp;
+    **Have a question or need help?**
+
+    ---
+
+    Ask a question on our [discussion board] and get in touch with our community
+
+    ---
+
+    [:octicons-arrow-right-24: Ask a question][discussion board]
+
+</div>
+
+### Contributing
+
+<div class="grid cards" markdown>
+
+-   :material-source-pull: &nbsp;
+    **Want to create a pull request?**
+
+    ---
+
+    Learn how to create a comprehensive and useful pull request (PR)
+
+    ---
+
+    [:octicons-arrow-right-24: Create a pull request][create a pull request]
+
+</div>
+
+  [report a bug]: reporting-a-bug.md
+  [report a docs issue]: reporting-a-docs-issue.md
+  [request a change]: requesting-a-change.md
+  [discussion board]: https://github.com/kyverno/chainsaw/discussions
+  [add translations]: adding-translations.md
+  [create a pull request]: making-a-pull-request.md
+
+## Checklist
+
+Before interacting within the project, please consider the following questions to ensure you're using the correct issue template and providing all necessary information.
+
+!!! warning "Issues, discussions, and comments are forever"
+
+    Please note that everything you write is permanent and will remain for everyone to read – forever. Therefore, please always be nice and constructive, follow our contribution guidelines, and comply with our [Code of Conduct].
+
+### Before creating an issue
+
+- Are you using the appropriate issue template, or is there another issue template that better fits the context of your request?
+- Have you checked if a similar bug report or change request has already been created, or have you stumbled upon something that might be related?
+- Did you fill out every field as requested and provide all additional information needed to comprehend your request?
+
+### Before asking a question
+
+- Is the topic a question for our [discussion board], or is it a bug report or change request that should be raised on our [issue tracker]?
+- Is there an open discussion on the topic of your request? If the answer is yes, does your question match the direction of the discussion, or should you open a new discussion?
+- Did you provide our community with all the necessary information to understand your question and help you quickly, or can you make it easier to help you?
+
+### Before commenting
+
+- Is your comment relevant to the topic of the current page, post, issue, or discussion, or is it better to create a new issue or discussion?
+- Does your comment add value to the conversation? Is it constructive and respectful to our community and maintainers? Could you just use a [:octicons-smiley-16: reaction][reaction] instead?
+
+  [Code of Conduct]: https://github.com/kyverno/chainsaw/blob/main/CODE_OF_CONDUCT.md
+  [reaction]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/
+
+## Rights and responsibilities
+
+As maintainers, we are entrusted with the responsibility to moderate communication within our community, including the authority to close, remove, reject, or edit issues, discussions, comments, commits, and to block users who do not align with our contribution guidelines and our [Code of Conduct]. This role requires us to be actively involved in maintaining the integrity and positive atmosphere of our community. Upholding these standards decisively ensures a respectful and inclusive environment for all members.
+
+### Code of Conduct
+
+Our [Code of Conduct] outlines the expectation for all community members to treat one another with respect, employing inclusive and welcoming language. Our commitment is to foster a positive and supportive environment, free of inappropriate, offensive, or harmful behavior.
+
+We take any violations seriously and will take appropriate action in response to uphold these values.[^1]
+
+  [^1]: 
+    **Warning and blocking policy:**
+    Given the increasing popularity of our project and our commitment to a healthy community, we've defined clear guidelines on how we proceed with violations:
+
+    1.1. **First warning:** Users displaying repeated inappropriate, offensive, or harmful behavior will receive a first warning. This warning serves as a formal notice that their behavior is not in alignment with our community standards and Code of Conduct. The first warning is permanent.
+
+    1.2. **Second warning and opportunity for resolution:** If the behavior persists, a second warning will be issued. Upon receiving the second warning, the user will be given a 5-day period for reflection, during which they are encouraged to publicly explain or apologize for their actions. This period is designed to offer an opportunity for openly clearing out any misunderstanding.
+
+    1.3. **Blocking:** Should there be no response or improvement in behavior following the second warning, we reserve the right to block the user from the community and repository. Blocking is considered a last resort, used only when absolutely necessary to protect the community's integrity and positive atmosphere.
+
+    Blocking has been an exceptionally rare necessity in our overwhelmingly positive community, highlighting our preference for constructive dialogue and mutual respect. It aims to protect our community members and team.
+
+### Incomplete issues and duplicates
+
+We have invested significant time and effort in the setup of our contribution process, ensuring that we assess the essential requirements for reviewing and responding to issues effectively. Each field in our issue templates is thoughtfully designed to help us fully understand your concerns and the nature of your matter. We encourage all members to utilize the search function before submitting new issues or starting discussions to help avoid duplicates. Your cooperation is crucial in keeping our community's discussions constructive and organized.
+
+  - **Mandatory completion of issue templates:** We need all of the information required in our issue templates because it ensures that every user and maintainer, regardless of their experience, can understand the content and severity of your bug report or change request.
+
+  - **Closing incomplete issues:**
+  We *reserve the right to close issues lacking essential information*, such as but not limited to [minimal reproductions] or those not adhering to the quality standards and requirements specified in our issue templates. Such issues can be reopened once the missing information has been provided.
+
+  - **Handling duplicates:** To maintain organized and efficient communication within our [issue tracker] and [discussion board], we *reserve the right to close any duplicated issues or lock duplicated discussions*. Opening multiple channels to ask the same question or report the same issue across different forums hinders our ability to manage and address community concerns effectively. This approach is vital for efficient time management, as duplicated questions can consume the time of multiple team members simultaneously. Ensuring that each issue or discussion is unique and progresses with new information helps us to maintain focus and support our community.
+
+    We further *reserve the right to immediately close discussions or issues that are reopened without providing new information* or simply because users have not yet received a response to their issue/question, as the issue is marked as incomplete.
+
+  - **Limitations of automated tools:**  While we believe in the value and efficiency that automated tools bring to identifying potential issues (such as those identified by Lighthouse, Accessibility tools, and others), simply submitting an issue generated by these tools does not constitute a complete bug report. These tools sometimes produce verbose outputs and may include false positives, which necessitate a critical evaluation. You are of course welcome to attach generated reports to your issue. However, this does not substitute the requirement for a minimal reproduction or a thorough discussion of the findings. *We reserve the right to mark these issues as incomplete and close them.* This practice ensures that we are addressing genuine concerns with precision and clarity, rather than navigating through extensive automated outputs.
+
+  <!-- [minimal reproductions]: ../guides/creating-a-reproduction.md -->
@@ -0,0 +1,111 @@
+# Pull Requests
+
+You can contribute to Chainsaw by making a [pull request] that will be reviewed by maintainers and integrated into the main repository when the changes made are approved. You can contribute bug fixes, documentation changes, or new functionalities.
+
+[pull request]: https://docs.github.com/en/pull-requests
+
+!!! note "Considering a pull request"
+
+    Before deciding to spend effort on making changes and creating a pull request, please discuss what you intend to do. If you are responding to what you think might be a bug, please issue a [bug report] first. If you intend to work on documentation, create a [documentation issue]. If you want to work on a new feature, please create a [change request].
+
+    Keep in mind the guidance given and let people advise you. It might be that there are easier solutions to the problem you perceive and want to address. It might be that what you want to achieve can already be done by configuration or [customization].
+
+[bug report]: reporting-a-bug.md
+[documentation issue]: reporting-a-docs-issue.md
+[change request]: requesting-a-change.md
+<!-- [customization]: ../customization.md -->
+
+## Learning about pull requests
+
+Pull requests are a concept layered on top of Git by services that provide Git hosting. Before you consider making a pull request, you should familiarize yourself with the documentation on GitHub, the service we are using. The following articles are of particular importance:
+
+1. [Forking a repository]
+2. [Creating a pull request from a fork]
+3. [Creating a pull request]
+
+Note that they provide tailored documentation for different operating systems and different ways of interacting with GitHub. We do our best in the documentation here to describe the process as it applies to Chainsaw but cannot cover all possible combinations of tools and ways of doing things. It is also important that you understand the concept of a pull-request in general before continuing.
+
+[Forking a repository]: https://docs.github.com/en/get-started/quickstart/fork-a-repo
+[Creating a pull request from a fork]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork
+[Creating a pull request]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request
+
+## Pull request process
+
+In the following, we describe the general process for making pull requests. The aim here is to provide the 30k ft overview before describing details later on.
+
+### Preparing changes and draft PR
+
+The diagram below describes what typically happens to repositories in the process or preparing a pull request. We will be discussing the review-revise process below. It is important that you understand the overall process first before you worry about specific commands. This is why we cover this first before providing instructions below.
+
+``` mermaid
+sequenceDiagram
+  autonumber
+
+  participant chainsaw
+  participant PR
+  participant fork
+  participant local
+
+  chainsaw ->> fork: fork on GitHub
+  fork ->> local: clone to local
+  local ->> local: branch
+  loop prepare
+    loop push
+      loop edit
+        local ->> local: commit
+      end
+      local ->> fork: push
+    end
+    chainsaw ->> fork: merge in any changes
+    fork ->>+ PR: create draft PR
+    PR ->> PR: review your changes
+  end
+```
+
+1. Fork the Repository: Fork the Chainsaw repository on GitHub to create your own copy.
+2. Clone to Local: Clone your fork to your local machine.
+3. Create a Branch: Create a topic branch for your changes.
+4. Set Up Development Environment: Follow the instructions to set up a development environment.
+5. Iterate and Commit: Make incremental changes and commit them with meaningful messages.
+6. Push Regularly: Push your commits to your fork regularly.
+7. Merge Changes from Upstream: Regularly merge changes from the original Chainsaw repository to avoid conflicts.
+8. Create a Draft Pull Request: Once satisfied with your changes, create a draft pull request for early feedback.
+9. Review and Revise: Review your work critically, address feedback, and refine your changes.
+
+### Finalizing
+
+Once you are happy with your changes, you can move to the next step, finalizing
+your pull request and asking for a more formal and detailed review. The diagram
+below shows the process:
+
+``` mermaid
+sequenceDiagram
+  autonumber
+  participant chainsaw
+  participant PR
+  participant fork
+  participant local
+
+  activate PR
+  PR ->> PR: finalize PR
+  loop review
+    loop discuss
+      PR ->> PR: request review
+      PR ->> PR: discussion
+      local ->> fork: push further changes
+    end
+    PR ->> chainsaw: merge (and squash)
+    deactivate PR
+    fork ->> fork: delete branch
+    chainsaw ->> fork: pull
+    local ->> local: delete branch
+    fork ->> local: pull
+  end
+
+```
+
+1. Finalize PR: Signal that your changes are ready for review.
+2. Request Review: Ask the maintainer to review your changes.
+3. Discuss and Revise: Engage in discussions, make necessary revisions, and iterate.
+4. Merge and Squash: Once approved, the maintainer will merge and possibly squash your commits.
+5. Clean Up: Delete the branch used for the PR from both your fork and local clone.