|
| 1 | +# Contributor guidelines |
| 2 | + |
| 3 | +We are excited that you're interested in contributing to this project! Your efforts help us improve and grow. |
| 4 | + |
| 5 | +# Ways to contribute |
| 6 | + |
| 7 | +There are many ways for you to contribute to the Checkly operator, for example: |
| 8 | + |
| 9 | +- **User feedback:** Share your feedback and impressions about the operator. Your insights are incredibly helpful for us to further improve and develop the project. |
| 10 | +- **Documentation:** Help us identify and fix gaps or issues in our documentation. |
| 11 | +- **Bug reports & fixes:** Encountered a bug or unexpected behavior? Please report it to us, and if possible, contribute a fix. |
| 12 | +- **Feature enhancements:** Propose or work on new features for the operator. |
| 13 | + |
| 14 | +# Finding an issue |
| 15 | + |
| 16 | +You can discover reported bugs, feature ideas, or discussion topics in the [Issues section](https://github.com/checkly/checkly-operator/issues) of this repository. We strive to tag issues with labels such as "good first issue" and "help wanted" to indicate which tasks are up for grabs. |
| 17 | + |
| 18 | +# How to get in touch |
| 19 | + |
| 20 | +You can reach us anytime on **#checkly-k8s-operator** channel in the [Checkly community Slack](https://www.checklyhq.com/slack). |
| 21 | + |
| 22 | +# Commit message guidelines |
| 23 | +We follow the **Angular Conventional Commits** format to ensure consistent and meaningful commit messages, which streamline our release process. |
| 24 | + |
| 25 | +Here’s the basic format: |
| 26 | + |
| 27 | +- `<type>(<scope>): <description>` |
| 28 | + |
| 29 | + - **Type**: What kind of change you’re making, like: |
| 30 | + - `feat`: Adding a new feature. |
| 31 | + - `fix`: Fixing a bug. |
| 32 | + - `docs`: Updating documentation. |
| 33 | + - `style`: Code style changes (e.g., formatting). |
| 34 | + - `refactor`: Changing code without affecting how it works. |
| 35 | + - `test`: Adding or updating tests. |
| 36 | + - `chore`: Routine tasks (e.g., updating dependencies). |
| 37 | + |
| 38 | + - **Scope**: Where the change happens (e.g., `operator`, `readme`). |
| 39 | + |
| 40 | + - **Description**: A short summary of the change. |
| 41 | + |
| 42 | +Some examples: |
| 43 | +- `docs(readme): Add commit message guidelines` |
| 44 | +- `fix(operator): Fix timeout issue in deployment` |
| 45 | + |
| 46 | +For more info, check out the [Conventional Commits guide](https://www.conventionalcommits.org/en/v1.0.0/). |
| 47 | + |
| 48 | +# Contribution workflow |
| 49 | + |
| 50 | +Our general approach follows the "fork-and-pull" Git workflow: |
| 51 | + |
| 52 | +1. Fork the repository on GitHub. |
| 53 | +2. Clone the project to your local machine. |
| 54 | +3. Make your changes and commit them to a new branch. |
| 55 | +4. Push your branch to your forked repository. |
| 56 | +5. Open a Pull Request so we can review and discuss your changes. |
| 57 | + |
0 commit comments