We appreciate if users experiment with the library, use it in small projects and report issues they encounter. If you intend to contribute code, please read the section Pull request guidelines below, so you spend less time on administrative tasks.
The rest of the document goes into tools and infrastructure available for development.
If you plan to make bigger contributions, make sure to discuss them in a GitHub issue before opening a pull request (PR).
Since the library is evolving quickly, this avoids that multiple people work on the same thing, or that features don't integrate well,
causing a lot of rework. Also don't hesitate to talk to the developers in the #contrib-gdext channel on Discord!
This makes it easier to review changes, later reconstruct what happened when and -- in case of regressions -- revert individual commits. The exception are tiny changes of a few lines that don't bear semantic significance (typos, style, etc.). Larger code style changes should be split though.
If your pull request changes a single thing, please squash the commits into one. Avoid commits like "integrate review feedback" or "fix rustfmt".
Instead, use git commit --amend or git rebase -i and force-push follow-up commits to your branch (git push --force-with-lease).
Since we use the bors bot to merge PRs, we can unfortunately not squash commits upon merge.
In case you plan to work for a longer time on a feature/bugfix, consider opening a PR as a draft.
This signals that reviews are appreciated, but that the code is not yet ready for merge.
Non-draft PRs that pass CI are assumed to be mergeable (and maintainers may do so).
Further information for contributors, such as tools supporting you in local development, is available in the [godot-rust book]. The book also elaborates design principles and conventions behind our API.