1# Contributing guidelines
 2
 3Thank you (again) for your interest in the project!
 4
 5## Talk to us before commiting to a change
 6
 7We recommend you come and talk to us in the channel and/or open an issue
 8before you start working on a feature, to **see if it aligns with our goals**.
 9
10We'll do our best to review and discuss changes with you but we're also humans
11with other activities, please be patient with us too.
12
13## General guidelines
14
15The library is still **in development**, and while this is the case we adopt a
16**fail-fast** strategy, which is also a reason for the choice of the language.
17
18The earlier we catch bugs and fix them, the less chances they have to confuse
19users of our library, or make end-users give up on software developed using
20this library. This also helps improving other software in the ecosystem.
21
22## Keep commits short and meaningful
23
24To help with reviews, to facilitate reverts, reading and grepping through
25commit history, bisects: it is important for us that changes come in small and
26meaningful commits.
27
28That is, **don't bundle all the things in a single commit**, if a change can
29be added via different commits standalone and still make sense, then it's
30probably a good candidate for splitting.
31
32## Meta
33
34Do not forget to **update changelogs** and other crate metadata where necessary.
35
36Signing commits (`git commit -S`) and adding DCO bits (`git commit -s`) are
37welcome but not mandatory.
38
39## Ensure CI passes
40
41Code changes should **include documentation**. They should also **include
42tests** where appropriate, and pass the existing test suite.
43
44CI should pass to submit your changes. This is done by ensuring `cargo
45fmt` and `cargo test` pass (in the workspace). Please run `cargo fmt` as part
46of each of your commits.
47
48More thorough tests can be done locally with `act` or `forgejo-runner
49exec`, which is also what is run in the CI. We require docker to be setup for
50this to work.