The webfinger-rs project team welcomes contributions from the community.
This is a rough outline of what a contributor's workflow looks like:
- Create a topic branch from where you want to base your work
- Make commits of logical units
- Make sure your commit messages are in the proper format (see below)
- Push your changes to a topic branch in your fork of the repository
- Submit a pull request
Example:
git remote add upstream https://github.com/glyn/webfinger-rs.git
git checkout -b my-new-feature main
git commit -a
git push origin my-new-feature
Basic conventions around source file formatting are captured in the .editorconfig
file.
Many editors support that file natively. Others require a plugin, see https://editorconfig.org/.
Be sure to run any tests:
cargo test
When your branch gets out of sync with the glyn/webfinger-rs/main branch, use the following to update:
git checkout my-new-feature
git fetch -a
git pull --rebase upstream main
git push --force-with-lease origin my-new-feature
If your PR fails to pass CI or needs changes based on code review, you'll most likely want to make some changes and push them to your branch.
Be sure to add a comment to the PR indicating your new changes are ready to review, as GitHub does not generate a notification when you git push.
We follow the conventions on How to Write a Git Commit Message.
When opening a new issue, try to roughly follow the commit message format conventions above.
Create a release using the Github web interface, ensuring that version
is set
to a suitable value in Cargo.toml
. A Github action will automatically populate
the release with Linux and Windows binaries.