Change Requests¶

Chainsaw by Kyverno is a powerful tool for end-to-end testing. Serving a wide range of use cases, we value every idea or contribution from our community. Please follow this guide before submitting your change request in our public issue tracker. This helps us better understand the proposed change and how it will benefit our community.

Before Creating an Issue¶

Before you invest time in submitting a change request, answer these questions to determine if your idea is a good fit for Chainsaw and matches the project's philosophy and tone.

It's Not a Bug, It's a Feature¶

Change requests suggest minor adjustments, new features, or influence the project's direction. They are not intended for reporting bugs. Refer to our bug reporting guide for that.

Look for Sources of Inspiration¶

If your idea is implemented in another tool or framework, collect information on its implementation. This helps us evaluate its fit more quickly.

Connect with Our Community¶

Our discussion board is the best place to connect with our community. Seeking input from other users helps implement features that benefit a larger number of users.

Start a discussion

Issue Template¶

After doing the preliminary work, create a change request. Follow these steps:

• Title
• Context optional
• Description
• Related Links
• Use Cases
• Visuals optional
• Checklist

Title¶

A good title is short and descriptive, summarizing the idea so the potential impact and benefit can be inferred.

Context optional¶

Provide additional context to help us understand what you are trying to achieve. Explain the circumstances and relevant settings without describing the change request itself.

Description¶

Provide a detailed and clear description of your idea. Explain why your idea is relevant to Chainsaw and should be implemented here, not in one of its dependencies.

• Explain the what, not the why – focus on describing the change request precisely.
• Keep it short and concise – be brief and to the point.
• One idea at a time – if you have multiple ideas, open separate change requests for each.

Related Links¶

Provide any relevant links to issues, discussions, or documentation sections related to your change request. This helps us gain additional context.

Use Cases¶

Explain how your change request would work from an author's and user's perspective. What is the expected impact, and why does it benefit other users? Would it potentially break existing functionality?

Visuals optional¶

If you have any visuals, such as sketches, screenshots, mockups, or external assets, present them in this section. If you have seen this change used in other tools, showcase and describe its implementation.

Checklist¶

Thanks for following the guide and creating a high-quality change request. The checklist ensures that you have read this guide and provided all necessary information for us to review your idea.

We'll take it from here.

Rejected Requests¶

Your change request got rejected? We're sorry for that. We understand it can be frustrating, but we always need to consider the needs of our entire community. If you're unsure why your change request was rejected, please ask for clarification.

We consider the following principles when evaluating change requests:

• Alignment with the project's vision and tone
• Compatibility with existing features and plugins
• Compatibility with all screen sizes and browsers
• Effort of implementation and maintenance
• Usefulness to the majority of users
• Simplicity and ease of use
• Accessibility

If your idea was rejected, you can always implement it via [customization]. If you're unsure how or want to know if someone has already done it, get in touch with our community on the discussion board.