> [!WARNING] > We are not looking for contributions at this point of the development, but we > will update this page when we are ready. # Contributing Guidelines ## Code of Conduct This project and everyone participating in it is governed by our [Code of Conduct](./CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to `TODO: ADD_EMAIL_HERE`. ## How can I contribute? - Reporting bugs - Proposing new features or improvements - For bug reports & proposals, consider the following: - Always be respectful, and mind the [Code of Conduct](./CODE_OF_CONDUCT.md) - 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](./CODE_OF_CONDUCT.md) - Backwards compatibility is mandatory most of the times, please try to preserve it. - Respect the current coding style, to avoid style inconsistencies. ## Tooling & Workflow > [!WARNING] > TODO ## Code Contributions: Acceptance Criteria In order for us to accept contributions, the merge request must fulfill certain requirements: ### Style Guide > [!WARNING] > TODO ### Commit signatures For security & regulations compliance, commits must be cryptographically signed by [PGP](https://www.openpgp.org/)/[GPG](https://gnupg.org/), or SSH ([since git v2.34](https://github.blog/2021-11-15-highlights-from-git-2-34/)). You can read more about this topic here: - [Git's documentation](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work) - [Github's documentation](https://help.github.com/en/github/authenticating-to-github/signing-commits) - [Gitlab's documentation](https://docs.gitlab.com/ee/user/project/repository/gpg_signed_commits/). - [Signing Git commits with your SSH key](https://calebhearth.com/sign-git-with-ssh) ### Commit messages Commit messages must be properly formatted (following the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) 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](https://semver.org/) rules) ### Branch history 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 ### Other considerations [EIPs (EPM Improvement Proposals)](./eips/index.md) might also be important to decide if some contributions are acceptable or not. It's a good idea to familiarize yourself with these documents before start contributing.