How to contribute

Godot is a community-driven project. This section covers how to actually work in this repo: where to put a change, how to format it, how to test it, and how to get it reviewed.

Authoritative sources

• CONTRIBUTING.md at the repo root is the short rules document.
• The longer Contributors documentation covers process, guidelines, and ownership.
• The Engine development guide on docs.godotengine.org has narrative tutorials on adding features, modules, and scripting bindings.

Pages in this section

• Development workflow — branch, code, push, PR.
• Testing — doctest, integration tests, CI matrix.
• Debugging — error logs, profiler, remote debugger.
• Patterns and conventions — coding style, error handling, threading.
• Tooling — clang-format, clang-tidy, ruff, mypy, the pre-commit hooks.

Communication

• Godot Contributors Chat: https://chat.godotengine.org — engine developers hang out here, organized by area channel.
• Bug tracker: https://github.com/godotengine/godot/issues — report engine bugs (use a Minimal Reproduction Project).
• Feature proposals: https://github.com/godotengine/godot-proposals — the main repo doesn't accept feature proposals; the proposals repo does.
• Translations: https://hosted.weblate.org/projects/godot-engine/ — Weblate hosts editor + class-reference translations.

Pull request expectations

The summary, taken from CONTRIBUTING.md and the contributor guide:

1. One PR per topic. Avoid mega-PRs; reviewers will ask you to split anyway.
2. Discuss bigger changes first. New features should generally have a proposal accepted before a PR shows up.
3. Keep commits clean. Small commits, imperative-mood titles ("Fix X", "Add Y"), no merge commits (use git pull --rebase).
4. Document anything exposed to scripting. If your change adds methods, properties, or signals to a ClassDB-bound class, update the corresponding XML in doc/classes/. The CI will fail if doc coverage drops.
5. Add unit tests when fixing bugs or adding non-trivial logic. The bar isn't 100% coverage, but tests are strongly preferred for anything that can be tested without a windowing system.
6. Run pre-commit locally before pushing — see Tooling.
7. Match existing style. clang-format, ruff, and mypy are enforced; matches the existing patterns inside the file you're editing for everything else.
8. Accessibility / UX matters for editor PRs. Editor changes typically need a maintainer's UX review.

AI disclosure

The CONTRIBUTING.md includes a (currently commented-out) note about AI agent disclosure: agents are expected to flag PRs and issues with 🤖 in the title plus an > [!INFO] *AI disclosure*: … block in the description. The detail varies; check CONTRIBUTING.md at the time you contribute.

Code of conduct

The project follows the standard contributor covenant; rude or hostile behaviour is not tolerated. Reports go to the moderation team via the Contributors Chat.