This project and everyone participating in it is governed by our Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to [email protected].
- Reporting bugs
- Proposing new features or improvements
- For bug reports & proposals, consider the following:
- Always be respectful, and mind the Code of Conduct
- Check if someone else already reported that bug or proposed that idea.
- Try to be thorough and detailed with your explanations, to help others to understand them and take proper action.
- Improving the current documentation
- Contributing code
- Always be respectful, and mind the Code of Conduct
- Backwards compatibility is almost sacred, please try to preserve it.
- Try to respect the current coding style, to avoid style inconsistencies.
In order for us to accept contributions, the merge request must fulfill certain requirements:
There is no "official" style guide, although we enforce style through automated tools, such as Prettier and ESLint.
For security & regulations compliance, commits must be cryptographically signed by PGP/GPG, or SSH (since git v2.34). You can read more about this topic here:
- Git's documentation
- Github's documentation
- Gitlab's documentation.
- Signing Git commits with your SSH key
Commit messages must be properly formatted (following the Conventional Commits rules). The reasons behind this decision are many:
- The project's history has to be "easy" to read.
- It's easier to extract statistics from the commit logs.
- It's easier to generate useful changelogs.
- This practice enforces that committers think twice about the nature of their contributions.
- It allows us to automate version numbering (following Semantic Versioning rules)
The merge request's commits have to present a "clean" history, git rebase is
your friend. This means:
- linear history
- commit messages matching what the commit does
- no "experimental" commits + their revert commits