All contributions are welcome. Ideas, code, documentation, production experiences, bugfixes... we only need to define some key ideas in order to make this more efficient.
- Follow the Kubernetes API conventions
- Embrace the GitOps principles
- Simplicity first
We have a development guide at your disposal so you can quickly setup an environment to develop locally.
Creating a new issue it's generally a good way to share your ideas and get feedback. We consider creating good issues and documentation its part of the creative process, and we don't want to interfere on it. However, it's encouraged to provide as much context as possible. Feel free to talk about a specific use case, show the maintainers what we are trying to solve.
Explore the available labels in order to proper categorize it and get the fastest feedback. Labels for customer-originated featured and bugs are for tracking purposes only, and not a guarantee that a specific feature or bug will be in a given release.
If the contribution it's a bugfix, a little feature or documentation improvement that could be implemented in, lets say, a couple of days at maximum, one could go directly for a PR. It's fine.
In general, contributions should be done by the typical fork workflow. In this workflow, developers fork this repository and then just submit pull requests to this one.
Whenever you are interacting, just ensure that your interaction (issue, comment, reply ...) passes the T.H.I.N.K test, by asking the following questions. Is it ...
T. Truthful? H. Helpful? I. Inspiring/Interesting? N. Necessary? K. Kube-friendly?