Bug triage guidelines

This page describes the typical workflow of the bug triage team aka bugsquad when handling issues and pull requests on Godot's GitHub repository. It is bound to evolve together with the bugsquad, so do not hesitate to propose modifications to the following guidelines.

Issues management

GitHub proposes various features to manage issues:

  • Set one or several labels from a predefined list

  • Set one milestone from a predefined list

  • Keep track of the issue in the project dashboard

  • Define one contributor as "assignee" among the Godot engine organization members

As the Godot engine organization on GitHub currently has a restricted number of contributors, we do not use assignees extensively for now. All contributors are welcome to take on any issue, if relevant after mentioning it on the issue ticket and/or discussing the best way to resolve it with other developers.

For the time being we do not use the project dashboard feature either.

As far as possible, we try to assign labels (and milestones, when relevant) to both issues and pull requests.

Обозначения на карте

The following labels are currently defined in the Godot repository:


  • Archived: either a duplicate of another issue, or invalid. Such an issue would also be closed.

  • Bug: describes something that is not working properly.

  • Confirmed: has been confirmed by at least one other contributor than the bug reporter (typically for Bug reports). The purpose of this label is to let developers know which issues are still reproducible when they want to select what to work on. It is therefore a good practice to add in a comment on what platform and what version or commit of Godot the issue could be reproduced; if a developer looks at the issue one year later, the Confirmed label may not be relevant anymore.

  • Discussion: the issue is not consensual and needs further discussion to define what exactly should be done to address the topic.

  • Documentation: issue related to the documentation. Mainly to request enhancements in the API documentation. Issues related to the ReadTheDocs documentation should be filed on the godot-docs repository.

  • Enhancement: describes a proposed enhancement to an existing functionality.

  • Feature proposal: describes a wish for a new feature to be implemented.

  • Junior job: the issue is assumed to be an easy one to fix, which makes it a great fit for junior contributors who need to become familiar with the code base.

  • Needs rebase: the issue need a Git rebase to be merged.

  • Needs testing: the issue/pull request could not be completely tested and thus need further testing. This can mean that it needs to be tested on different hardware/software configurations or even that the steps to reproduce are not certain.

  • Performance: issues that directly impact engine or editor performance. Can also be used for pull requests that improve performance or add low-end-friendly options. Should not be coupled with Usability.

  • PR welcome / Hero wanted!: Contributions for issues with these labels are especially welcome. Note that this doesn't mean you can't work on issues without these labels.

  • Regression: the bug appeared after a stable release not exhibiting the bug was released.

  • Salvageable: the pull request can't be merged due to design issues or merge conflicts and its author is not active anymore. However, it can still be picked up by an external contributor to bring it to a mergeable state. To do so, you need to open a new pull request based on the original pull request.

  • Tracker: issue used to track other issues (like all issues related to the plugin system).

  • Usability: issues that directly impact user usability. Should not be coupled with Performance.

Категории используются для общей сортировки проблем. При необходимости они могут быть объединены, например, проблема может быть помечена как Улучшение и Удобство одновременно, если это проблема улучшения удобства использования. Или Feature proposal и Discussion, если это неконсенсусный запрос функции, или запрос, который недостаточно точен для работы над ним.


  • 2D: relates to 2D-specific issues. Should be coupled with one of the labels below, and should not be coupled with 3D.

  • 3D: relates to 3D-specific issues. Should be coupled with one of the labels below, and should not be coupled with 2D.

  • Assetlib: относится к проблемам с библиотекой активов.

  • Audio: относится к аудиофункциям (низкий и высокий уровень).

  • Buildsystem: относится к вопросам сборки, связанным либо с системой сборки SCons, либо с особенностями компилятора.

  • Core: все, что связано с основным движком. Это может быть разделено позже, так как это довольно большая тема.

  • Drivers: относится к проблемам с драйверами, используемыми двигателем.

  • Editor: относится к проблемам в редакторе (в основном к пользовательскому интерфейсу).

  • GDNative: относится к модулю GDNative.

  • GDScript: относится к GDScript.

  • Mono: относится к привязке C# / Mono.

  • Network: относится к работе с сетями.

  • Physics: относится к физическому движку (2D/3D).

  • Plugin: относится к проблемам, возникающим при написании плагинов.

  • Porting: относится к некоторым конкретным платформам.

  • Rendering: относится к движкам 2D и 3D рендеринга.

  • VisualScript: относится к проблемам с языком визуальных сценариев.

Вопросы обычно соответствуют только одной теме, хотя не исключено, что вопросы будут соответствовать двум темам. Общая идея заключается в том, что за всеми темами будут стоять специализированные команды авторов, и они смогут сосредоточиться на вопросах, помеченных темой их команды.


Android, HTML5, iOS, Linux, macOS, Windows, UWP

По умолчанию предполагается, что данная проблема относится ко всем платформам. Если используется один из ярлыков платформы, то он является эксклюзивным, и предыдущее предположение больше не действует (поэтому, если это ошибка, например, только для Android и Linux, выберите эти две платформы).

Основные этапы

Milestones correspond to planned future versions of Godot for which there is an existing roadmap. Issues that fit in the said roadmap should be filed under the corresponding milestone; if they don't correspond to any current roadmap, they should be left without milestone. As a rule of thumb, an issue corresponds to a given milestone if it concerns a feature that is new in the milestone, or a critical bug that can't be accepted in any future stable release, or anything that Juan wants to work on right now. :)

Вкладчики могут выбирать проблемы независимо от назначенной им вехи; если предлагается исправление ошибки, которая не считалась срочной и поэтому не имела вехи, оно, вероятно, все равно будет очень приветствоваться.