Skip to content

Latest commit

 

History

History
78 lines (47 loc) · 4.99 KB

CONTRIBUTING.md

File metadata and controls

78 lines (47 loc) · 4.99 KB

Contributing Guidelines

Thank you for your interest in contributing to the project. Whether it's a bug report, new feature, correction, or additional documentation, we greatly value feedback and contributions from our community.

Please read through this document before submitting any issues or pull requests to ensure we have all the necessary information to effectively respond to your bug report or contribution.

Reporting Bugs/Feature Requests

We welcome you to use the GitHub issue tracker to report bugs or suggest features.

Before filing an issue, please check to see if there's an existing or recently closed issue. If a similar issue already exists, please consider adding an upvote and your own details.

Please try to include detailed descriptions in issues. Details like these are incredibly useful:

  • A reproducible test case or series of actions you took to discover the issue;
  • The version being used, or commit if a local build;
  • Any modifications you've made that may be relevant to the issue;
  • Any details about your environment or deployment that may be interesting

Note to keep things tidy and moving along, the maintainers may close issues that appear to be duplicates, are incomplete, or have no discussion for a period of time.

If an issue is closed, and you feel like it needs to be open, we are always open to discussion.

Contributing via Pull Requests

Contributions via pull requests are much appreciated. Before sending us a pull request, please:

  1. Check existing open or recently merged pull requests to ensure someone else hasn't addressed the problem already.
  2. Allow for time to discuss any significant work. Conversation can be driven on issues, or Work-in-progress (WIP) PRs can work as well (use "WIP" in your PR title). This is an active project with specific goals, it's best to discuss major changes.
  3. Work against the latest source on the main branch.

Unless the work is very obvious (e.g. a few lines to fix a bug), please make sure your PR has a related Issue. If there are no existing issues, please create one to describe the need.

If you are planning a new feature or otherwise significant changes or refactors, consider creating a design proposal. We can help make a call with you, and may suggest you create one depending on the scope of your PR.

To send create a Pull Request, please:

  1. Fork the repository.
  2. Make commits in your fork.
    • Please focus on the specific change you are contributing. While many PRs require multiple commits, if commits start addressing other issues, please migrate these changes to another PR.
    • Please use single-intent commits, squashing intermediate updates and fixes. This helps PR review and makes rebases and merges smoother.
    • If changes include large scale reformats, please separate these changes into their own commits. This makes it easier to review reformats and implementation changes together in the same PR.
    • Please use clear commit messages, describing your committed changes.
  3. Please ensure local tests pass.
    • We can't start meaningful review and discussion if tests are failing.
    • Feel free to update any tests that require it; often failing tests are simply related to changes in the PR.
    • If you are adding new functionality, please include tests along with your changes.
    • This step is especially required when using agentic AI to help with the coding.
  4. Create a PR from your fork, answering any default questions in the pull request interface.
  5. Monitor for automated CI failures reported in the pull request, and stay involved in the conversation (followups, rebases, etc are all part of the process).

GitHub provides nice documentation on forking a repository and creating a pull request.

As with issues above, to keep things tidy and moving along, the maintainers may close PRs that appear to be duplicates, are incomplete and have no discussion for a period of time, or that don't follow the process in spirit.

If a PR is closed, and you feel like it needs to be open, we are always open to discussion.

Development setup

Setup the local environment to build and test the code locally.

Finding contributions to work on

Looking at the existing issues is a great way to find something to work on. As the project uses the default GitHub issue labels (enhancement/bug/duplicate/help wanted/invalid/question/wontfix), looking at any 'help wanted' issues is a great place to start.

Code of Conduct

This project has adopted the Kubernetes Community Code of Conduct

Security

If you discover a potential security issue in this project, we ask that you notify project maintainers via email at security@kro.run. Please do not create a public GitHub issue.

Licensing

See the LICENSE file for our project's licensing. We will ask you to confirm the licensing of your contribution.