Participate in Godot's development

The engine development is coordinated by teams and discussed on the Godot Contributors Chat. If you are serious about getting involved, you should join us there!

  • Engine code (mainly C++): If you are a programmer, you can contribute to Godot by working on its source code, or the source code of any other repository.

  • Documentation: Contribute documentation to improve the Godot Engine with your technical writing skills.

  • Translations (spoken languages other than English): Are you interested in making the Godot Engine more accessible to non-English speakers? Contribute to our community translations on Weblate.

  • Test and discuss pull requests: Every change to Godot starts with a pull request, and all pull requests need feedback. Even without knowing how to program, you can help by testing whether pull requests work as intended, by discussing whether new features are useful and appropriate, and giving feedback on how to improve fixes or new features.

  • Bugsquad & triage: With so many bug reports and pull requests being opened each day, the ◆ Triage team — also called bugsquad — is invaluable to keep things organized. If you'd like to get involved, please visit Introduction to issue triage!

Contribute engine code

You can theoretically propose and implement any kind of change to Godot. The community will discuss whether the change is needed and appropriate, and will make suggestions for how to improve it. Area maintainers consider community demand, priority, and complexity, and make a decision about whether to accept it.

Even if you already have some specific change in mind, in many cases you should report a bug or propose the change first. These are useful for maintainers to understand the change, and proposals especially are used to gauge community interest and challenge your solution idea.

Look for simple, relevant, and uncontroversial changes to contribute, especially at first. Here are some ideas:

Contribute documentation

Start contributing in the areas that you are most familiar with. This ensures that the added description will be based on experience and the necessary know-how, not just the name of a method or a property. We advise not to add low effort descriptions, no matter how appealing it may look. Such descriptions obscure the need for documentation and are hard to identify automatically.

See also

Following this principle is important and allows us to create tools for contributors. Such as the class reference's completion status tracker. You can use it to quickly find documentation pages missing descriptions.

If you decide to document a class, but don't know what a particular method does, don't worry. Leave it for now, and list the methods you skipped when you open a pull request with your changes. Another writer will take care of it.

You can still look at the method's implementation in Godot's source code on GitHub. If you have doubts, feel free to ask on the Godot Forum and Godot Contributors Chat.

Warning

Unless you make minor changes, like fixing a typo, we do not recommend using the GitHub web editor to edit the class reference's XML files. It lacks features to edit XML well, like keeping indentations consistent, and it does not allow amending commits based on reviews.

It also doesn't allow you to test your changes in the engine or with validation scripts as described in the class reference documentation.