Skip to content

Latest commit

 

History

History
73 lines (59 loc) · 2.97 KB

CONTRIBUTING.md

File metadata and controls

73 lines (59 loc) · 2.97 KB
Raw

Contributing Guidelines

Code of Conduct

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].

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
    • 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.

Tooling & Workflow

  1. We rely on PNPM to manage our dependencies.
    • Remember to always run pnpm install before starting to work on any project of the repository.

Code Contributions: Acceptance Criteria

In order for us to accept contributions, the merge request must fulfill certain requirements:

Style Guide

There is no "official" style guide, although we enforce style through automated tools, such as Biome

Commit signatures

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:

Commit messages

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)

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