Have you read the code of conduct?
Before you make your changes, check to see if an issue exists already for the change you want to make.
If you spot something new, open an issue using a template. We'll use the issue to have a conversation about the problem you want to fix.
Before making a pull request, please fork the repository and create a new branch.
When you're done making changes and you'd like to propose them for review, use the pull request template to open your PR (pull request).
If your PR is not ready for review and merge because you are still working on it, please convert it to draft and add to it the label wip (work in progress). This label allows to filter correctly the rest of PR not wip.
Suggest your change by opening an issue and starting a discussion.
Please add, if possible, a reviewer, assignees and labels to your issue and PR.
Please do:
- DO give priority to the current style of the project or file you're changing even if it diverges from the general guidelines.
- DO include tests when adding new features. When fixing bugs, start with adding a test that highlights how the current behavior is broken.
- DO especially follow our rules in the Contributing section of our code of conduct.
- DO write idiomatic golang code
Please do not:
- DON'T fill the issues and PR descriptions vaguely. The elements in the templates are there for a good reason. Help the team.
- DON'T surprise us with big pull requests. Instead, file an issue and start a discussion so we can agree on a direction before you invest a large amount of time.
Branch names must follow kebab-case pattern. Follow the pattern feature/<name> or fix/<name> (folder/<name>) when it is possible and add issue reference if applicable.
Commits must follow the <type>(<scope>): <subject> pattern, as stated in the Conventional Commits specification
Please report security vulnerabilities to [email protected]. Do NOT report security bugs via Github Issues.