We have a Code of Conduct that we expect all contributors to follow. Please read it before contributing.
We require all contributors to sign a Contributor License Agreement before we can accept any contributions.
To sign the CLA, please head over to cla.scuffle.cloud and sign the CLA.
We do not squash any commits, we prefer if commits are meaningful and descriptive but this is not required.
The body of the pull request should be a summary of the changes made in the pull request as well as a list of the tickets & issues that are affected by the changes.
The title of the pull request should be a short and descriptive title of the changes made in the pull request.
We use a custom changelog format, you can read more about it here.
We require that all public methods, types, and functions are documented, with ideally doc examples on how to use the method when applicable.
We have a ci job that will check that the code is formatted correctly, you can run just format to format the code locally.
We have a ci job that will check that the code is linted correctly, you can run just lint to lint the code locally.
A common issue with rust crates with many features is that some combinations of the features do not work together but are expected to do so. To prevent this we have created a tool to powerset test feature combinations. You can run just powerset <command> to run the powerset tests locally. We run these tests only when attempting to merge a PR via ?brawl merge or ?brawl try
When adding deps, we need to make sure their licenses are allowed, you can run just deny to check the licenses of the deps.
We have a ci job that will check that the docs are built correctly, you can run just docs to build the docs locally. You can preview the docs by running just docs-serve.
We have a ci job that will check that the tests are passing, you can run just test to run the tests locally.
You can also see the coverage of the tests generated by the command by either previewing the lcov.info file or by running just coverage-serve to serve the coverage report.
We use valgrind to check for memory leaks in our tests. You can run just valgrind to run the tests with valgrind. Some tests are disabled because they are tests based on timings and valgrind runs them much too slow. If you add a test that is based on timings, you should disable it with valgrind #[cfg(not(valgrind))].
Hackari is a way to improve build times when using workspaces. If you make any dependency changes, you should run just workspace-hack to update the hackari cache.
We use a custom bot named brawl to merge pull requests. When a PR has been approved by a maintainer, we will then do ?brawl merge to add the PR to the merge queue. The reason we do this is because we want to make sure that the PR is ready to be merged and that it has been tested with changes that were not directly present in the PR. Since we do not require PRs to be rebased before merging we want to make sure that the PR works on the latest main branch.
Releasing crates is done by running a workflow dispatch on the Create Release PR workflow with the crate name as the input. This will then create a new PR with the crate's version bumped and the changelog updated.
If you have any questions, please ask in the discord server or create an issue on the repo or in the discussion section
Please do not hesitate to ask questions; we are here to help you and make sure you are comfortable contributing to this project. If you need help following the design documents or need clarification about the codebase, please ask us, and we will help you.
Thank you for taking the time to read this document and for contributing to this project. We are very excited to have you on board, and we hope you enjoy your time here.