Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
89 lines (64 loc) · 3.6 KB

CONTRIBUTING.md

File metadata and controls

89 lines (64 loc) · 3.6 KB

👥 Contributing Guidelines

Contributions are encouraged!

A good place to start is by looking at good first issues.

Please read our code of conduct before contributing.

🔨 Tooling

Several tools are used to help maintain the quality of the codebase. These tools are used by the continuous integration tools to statically check submitted code. Therefore, to save time, it is a good idea to install these tools locally and run them before pushing your changes.

To get up and running, make sure:

  • You have git installed.
  • Ideally, you have Bash 4.0 or greater.
  • You have rustup installed.

All other tooling is downloaded automatically, such as cargo clippy and rustfmt.

To make sure you always run the githooks:

git config core.hooksPath .githooks

Alternatively, if you have nix (shell) installed, you can use the nix flake which sets up everything for you:

nix develop

Installing Nix

Nix is distributed as a small installer script on nixos.org. Below are the recommended commands. If you are not running a Linux distro, this will probably not work for you.

sh <(curl --proto '=https' --tlsv1.2 -L https://nixos.org/nix/install) --daemon

📝 Procedures

We standardise the process of creating issues and pull requests to make it easier to manage the project. Please adhere to these standards.

Note In general, it is better to only comment on open pull requests and issues. Comments on closed issues and pull requests are likely to be ignored.

❗ Submitting an Issue

  • Do use one of the provided templates if possible.
  • Do check if there are already similar issues or pull requests before submitting a new issue.
  • Do assign the relevant milestone to an issue if applicable.
  • Do reference other issues if applicable.

❓ Submitting a Pull Request

  • Do use the provided template.
  • Do check that there are no other pull requests that are doing the same thing. If you think your solution is better than an existing pull request, it is better to comment there first and engage in discussion before opening your own pull request.
  • Do reference other issues and pull requests that are relevant.
  • Do actively engage with the comments on the pull request. An active discussion might lead to an even better solution or new ideas.
  • Do add tests when fixing a bug or adding new functionality.
  • Do make sure that this PR is targets one single issue, as large pull requests are difficult to review and unlikely to be merged.
  • Do make sure that the base branch is the correct branch:
    • The base branch will never be main (unless you are a core contributor).
    • The base branch generally will be develop.
    • If there is a specific feature branch (though unlikely in practice), do use this as a base branch instead if relevant.

Git Branching Model

For all the below, every merge is preceded by a Pull Request.

  • New featuers branch off and are merged with the development branch.
  • Large features get their own branch, and sub-features branch from this branch and are merged with this branch, before the feature branch is merged with develop.
  • Once develop has amassed enough features for a new release, we new branch is created where a release is staged ( e.g. v0.3.1).
  • Once approved, the new feature branch is merged with master.
  • The new merged release is tagged, and a new release is published on GitHub and published to Cargo.