Cot welcomes contribution from everyone in the form of suggestions, bug reports, pull requests, and feedback. This document gives some guidance if you are thinking of helping us.
If you have a question, feedback, or feature request, please open an issue, a discussion, or join our Discord server to talk with us directly.
When reporting a bug or asking for help, please include enough details so that the people helping you can reproduce the behavior you are seeing. For some tips on how to approach this, read about how to produce a Minimal, Complete, and Verifiable example.
When making a feature request, please make it clear what problem you intend to solve with the feature, any ideas for how Cot could support solving that problem, any possible alternatives, and any disadvantages.
We're happy to help you get started contributing to Cot. If you're looking for a place to start, check out the good first issue label on the issue tracker. If you're looking for something more challenging, check out the help wanted label, or just talk to us directly. We're happy to help you get started.
We encourage you to check that the test suite passes locally before submitting a pull request with your changes. If anything does not pass, typically it will be easier to iterate and fix it locally than waiting for the CI servers to run tests for you.
We are also using pre-commit hooks to handle
formatting and linting. See the pre-commit website for installation
instructions. This handles formatting of all the files in the repository.
When adding a new dependency to the project, please consider if it's actually needed and if it's possible to avoid it. If it's not plausible, make sure that the dependency is well-maintained and has a permissive license.
When adding a new dependency, please add it to the Cargo.toml file of the
workspace root, not to the Cargo.toml file of the crate, even if it's
not being used in any other crate. This way, all the dependencies are in
one place, and it's easier to manage them. The only exception to this rule
is the examples directory – examples should have all their dependencies
(except for the cot crate) listed in their own Cargo.toml file, so it's
easier to copy them to a new project.
The dependency's version should be pinned to the least specific version
possible. This means you should avoid specifying the patch and minor version,
as long as it works with your patch. The CI will check if the project builds
with the minimum version specified in the Cargo.toml file. By doing this,
we ensure that the project is not tied to a specific version of the dependencies,
potentially avoiding duplicate dependencies in the tree, and, more importantly,
avoiding problems when one of the dependencies is yanked.
We follow the Code of Conduct.