1.8 KiB
Contributing to mariadb-operator 🦭
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.
Key ideas
- Follow the Kubernetes API conventions
- Embrace the GitOps principles
- Simplicity first
Development guide
We have a development guide at your disposal so you can quickly setup an environment to develop locally.
Issues
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.
Pull requests
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.
Conduct
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?