1# Contributing guidelines
 2
 3Thank you (again) for your interest in the project!
 4
 5## Talk to us before committing 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
22We will not accept changes (code or otherwise) created with the aid of "AI"
23tooling. "AI" models are trained at the expense of underpaid workers filtering
24inputs of abhorrent content, and does not respect the owners of input content.
25Ethically, it sucks.
26
27Nor will we accept changes (code or otherwise) that move xmpp-rs crates toward
28enterprise / surveillance / other toxic capitalist pursuits.
29
30## Keep commits short and meaningful
31
32To help with reviews, to facilitate reverts, reading and grepping through
33commit history, bisects: it is important for us that changes come in small and
34meaningful commits.
35
36That is, **don't bundle all the things in a single commit**, if a change can
37be added via different commits standalone and still make sense, then it's
38probably a good candidate for splitting.
39
40## Meta
41
42Do not forget to **update changelogs** and other crate metadata where necessary.
43
44Signing commits (`git commit -S`) and adding DCO bits (`git commit -s`) are
45welcome but not mandatory.
46
47## Ensure CI passes
48
49Code changes should **include documentation**. They should also **include
50tests** where appropriate, and pass the existing test suite.
51
52CI should pass to submit your changes. This is done by ensuring `cargo
53fmt` and `cargo test` pass (in the workspace). Please run `cargo fmt` as part
54of each of your commits.
55
56More thorough tests can be done locally with `act` or `forgejo-runner
57exec`, which is also what is run in the CI. We require docker to be setup for
58this to work.
59
60# Making a release
61
62We are using the [semver](https://semver.org/) versioning system.
63
64For each crate you are releasing:
65- Ensure there aren't urgent changes in the buffer waiting to be released too.
66  Even though increasing a number is cheap, the process to get there isn't
67  doing itself
68- Have a run of cargo clippy if it hasn't been done (TODO: Add to CI)
69- Ensure tests, docstrings and examples pass (TODO: Add `--all-features` to
70  CI.)
71- Ensure dependencies are up-to-date.
72- Update the `version` attribute in the `Cargo.toml` file.
73- Update the ChangeLog file with the version number, the release date etc.
74- Rework the ChangeLog if necessary. Add missing entries, merge duplicates,
75  unify wording, make sure everything is where it should be, add meta
76  information such as merge requests, etc.
77- Send all of this as a merge request.
78- If the change is significant enough, prepare a blog article about it.
79
80## For the person with commit access
81
82- `git tag -s` releases
83- `cargo publish`
84- Publish blog article
85- Promote on social media