Skip to content

Latest commit

 

History

History
63 lines (42 loc) · 4.47 KB

CONTRIBUTING.md

File metadata and controls

63 lines (42 loc) · 4.47 KB

Contributing

Thank you for being interested in contributing to the project, all contributions are welcome! See the kube-logging organization's CONTRIBUTING.md file for general contribution guidelines.

Please read the Organisation's Code of Conduct!

Ways of contributing

There are multiple ways you can help with the project.

Questions

The following channels are available for Logging operator related discussions:

Reporting an issue

Please use the appropriate template for your issue type (if applicable):

Security related issue (security vulnerability) The Kube Logging team and community take all security issues seriously. Thank you for improving the security of our projects. We appreciate your efforts and responsible disclosure and will make every effort to acknowledge your contributions. Please follow the Security Policy for the next steps.

Opening a pull request (PR)

Steps:

  1. Check if there is an open issue that you can reference in your pull request
  2. Fork the repository
  3. Create a new branch using git switch -c <branch-name>
  4. Make your modifications and add unit tests to cover most code branches, input fields, and functionality if possible1
  5. Run make fmt to run code formatting
  6. Run make generate to generate code, documentation, manifests, etc.
  7. Run make check to run license checks, linter, tests
  8. (Optional) run make lint-fix to fix trivial linting problems
  9. Commit your modifications (preferably many smaller commits) using git commit -s, because DCO check is required
  10. Push your commits (git push <fork_origin> <fork_name>) and open a pull request

See the For developers page in the documentation for details (e.g. setting up a development environment, adding documentation).

Using AI tools

AI-assisted development (GitHub Copilot, Claude, ChatGPT, Cursor, etc.) is welcome, but contributors remain fully responsible for every line they submit. The following guidelines apply:

  • Review everything you submit. Do not paste AI output directly into a PR without reading and understanding it. You are the author; the model is a tool.
  • Tests are not optional. AI-generated code must be covered by tests just like hand-written code. Follow the existing patterns — use the envtest-based integration tests and Ginkgo/Gomega style where appropriate.
  • No filler or hallucinated content. AI tools sometimes produce plausible-looking but incorrect code, wrong API references, or invented configuration options. Verify against the actual codebase and documentation before submitting.
  • Keep your changes focused. Do not submit large AI-generated refactors or reformatting unless that was the explicit goal. Unrelated changes mixed into a PR make reviews harder.
  • Respect licensing. Be aware that some AI tools may reproduce code from their training data. If you are uncertain about the origin of a code block, rewrite it yourself.
  • Run the checks. make check (license, lint, tests) must pass regardless of how the code was produced. AI-generated code is not exempt from project standards.

Add yourself to the production adopters list

If you use the Logging operator in a production environment, add yourself to the list of production adopters.🤘

Footnotes

  1. For bigger features please open a new Feature request issue where we can have a discussion about the proposed feature and the suggested test cases. ↩