85 lines
3.3 KiB
Markdown
85 lines
3.3 KiB
Markdown
# Contributing guidelines
|
|
|
|
Thank you (again) for your interest in the project!
|
|
|
|
## Talk to us before committing to a change
|
|
|
|
We recommend you come and talk to us in the channel and/or open an issue
|
|
before you start working on a feature, to **see if it aligns with our goals**.
|
|
|
|
We'll do our best to review and discuss changes with you but we're also humans
|
|
with other activities, please be patient with us too.
|
|
|
|
## General guidelines
|
|
|
|
The library is still **in development**, and while this is the case we adopt a
|
|
**fail-fast** strategy, which is also a reason for the choice of the language.
|
|
|
|
The earlier we catch bugs and fix them, the less chances they have to confuse
|
|
users of our library, or make end-users give up on software developed using
|
|
this library. This also helps improving other software in the ecosystem.
|
|
|
|
We will not accept changes (code or otherwise) created with the aid of "AI"
|
|
tooling. "AI" models are trained at the expense of underpaid workers filtering
|
|
inputs of abhorrent content, and does not respect the owners of input content.
|
|
Ethically, it sucks.
|
|
|
|
Nor will we accept changes (code or otherwise) that move xmpp-rs crates toward
|
|
enterprise / surveillance / other toxic capitalist pursuits.
|
|
|
|
## Keep commits short and meaningful
|
|
|
|
To help with reviews, to facilitate reverts, reading and grepping through
|
|
commit history, bisects: it is important for us that changes come in small and
|
|
meaningful commits.
|
|
|
|
That is, **don't bundle all the things in a single commit**, if a change can
|
|
be added via different commits standalone and still make sense, then it's
|
|
probably a good candidate for splitting.
|
|
|
|
## Meta
|
|
|
|
Do not forget to **update changelogs** and other crate metadata where necessary.
|
|
|
|
Signing commits (`git commit -S`) and adding DCO bits (`git commit -s`) are
|
|
welcome but not mandatory.
|
|
|
|
## Ensure CI passes
|
|
|
|
Code changes should **include documentation**. They should also **include
|
|
tests** where appropriate, and pass the existing test suite.
|
|
|
|
CI should pass to submit your changes. This is done by ensuring `cargo
|
|
fmt` and `cargo test` pass (in the workspace). Please run `cargo fmt` as part
|
|
of each of your commits.
|
|
|
|
More thorough tests can be done locally with `act` or `forgejo-runner
|
|
exec`, which is also what is run in the CI. We require docker to be setup for
|
|
this to work.
|
|
|
|
# Making a release
|
|
|
|
We are using the [semver](https://semver.org/) versioning system.
|
|
|
|
For each crate you are releasing:
|
|
- Ensure there aren't urgent changes in the buffer waiting to be released too.
|
|
Even though increasing a number is cheap, the process to get there isn't
|
|
doing itself
|
|
- Have a run of cargo clippy if it hasn't been done (TODO: Add to CI)
|
|
- Ensure tests, docstrings and examples pass (TODO: Add `--all-features` to
|
|
CI.)
|
|
- Ensure dependencies are up-to-date.
|
|
- Update the `version` attribute in the `Cargo.toml` file.
|
|
- Update the ChangeLog file with the version number, the release date etc.
|
|
- Rework the ChangeLog if necessary. Add missing entries, merge duplicates,
|
|
unify wording, make sure everything is where it should be, add meta
|
|
information such as merge requests, etc.
|
|
- Send all of this as a merge request.
|
|
- If the change is significant enough, prepare a blog article about it.
|
|
|
|
## For the person with commit access
|
|
|
|
- `git tag -s` releases
|
|
- `cargo publish`
|
|
- Publish blog article
|
|
- Promote on social media
|