Настанови щодо пошуку причин вад

На цій сторінці описано типовий робочий процес команди сортування помилок, також відомої як bugsquad, під час обробки проблем і запитів на отримання в репозиторії GitHub Godot. Він обов’язково розвиватиметься разом із командою жуків, тому не вагайтеся пропонувати зміни до наведених нижче інструкцій.

Керування вадами

For issue management, we use the following GitHub processes:

  • Each issue and pull request (PR) is categorized with a set of labels, sometimes called "tags".

  • Each PR is assigned to a milestone. Some issues can also be assigned to a milestone (see below).

  • Issues can have an assignee, who is a contributor among Godot maintainers.

  • Issues can be put in one or more projects.

  • PRs can be linked to one or more issues which they "fix" or "close".

We don't yet extensively use or rely on some other GitHub processes:

  • Issue close reasons (completed, not planned, duplicate). While we use these, it is not consistent, and older issues are all closed as "completed", so the issue close reason should not be relied on.

  • Issue types (Bug, Feature, Task).

  • Issue relationships.

We only use the assignees feature for Godot maintainers who are members of the Godot Engine GitHub organization, and even then not in all cases. For other issues, we track who is working on an issue by comments on the issue and linked pull requests. Most issues are available for any contributor to take on, after discussing it with other contributors. If you would like to work on an issue, first check that no one else is working on it, by looking for a linked pull request, a comment "claiming" the issue, or an assignee. If no one else is working on the issue, leave a comment on the issue to "claim" it and start working on it.

Мітки

Наступні мітки наразі визначені в репозиторії Godot:

Categories:

  • Archived: used to filter issues closed with a resolution other than "fixed".

    • For issues, added to all issues that are not resolved by engine or documentation changes. This includes duplicate issues, user error, or reports in the wrong repository. Since we don't rely on GitHub's issue close reasons (completed, not planned, and duplicate), it is possible for an issue to be closed as completed with the Archived label.

    • For PRs, added to all closed PRs that are not merged. This includes superseded or duplicate PRs, Git or GitHub mistakes, and valid PRs that end up not merged.

  • Порушує сумісність: описує щось, що можна виправити, лише порушивши сумісність із існуючими проектами.

  • Помилка: описує те, що не працює належним чином.

  • Cherrypick: описує щось, що може бути перенесено до стабільної гілки після об’єднання в гілку master.

  • Підтверджено: було підтверджено принаймні одним іншим учасником, окрім повідомлення про помилку (зазвичай для звітів про помилки). Мета цієї мітки— повідомити розробникам, які проблеми ще можна відтворити, коли вони хочуть вибрати, над чим працювати. Тому доцільно додати в коментарі, на якій платформі та в якій версії чи коміті Godot можна було б відтворити проблему; якщо розробник розглядає проблему через рік, позначка Підтверджено може більше не бути актуальною.

  • Збій: описує помилку, яка спричиняє збій двигуна. Ця мітка використовується лише для «жорстких» збоїв, а не для зависань.

  • Обговорення: питання не є консенсусним і потребує подальшого обговорення, щоб визначити, що саме слід зробити для вирішення теми.

  • Документація: пов’язана з документацією. PR з цією міткою покращують посилання на клас. Проблеми з цією міткою пов’язані або з неправильною документацією, або з повідомленнями користувачів про «помилки», які насправді є обмеженнями, які необхідно додатково задокументувати. Часто в парі з Обговоренням. Питання, пов’язані з документацією ReadTheDocs, слід зберігати в репозиторії godot-docs.

  • Покращення: описує запропоноване вдосконалення наявної функції.

  • Feature proposal: used for PRs adding new features which do not have a corresponding proposal use this label. The label is removed when a feature proposal is created and linked. The main Godot repository no longer accepts feature requests as issues. Please use the godot-proposals repository instead.

  • Для PR-зустрічі: питання потрібно обговорити на зустрічі за запитом на підключення. Ці зустрічі є публічними та проводяться в чаті учасників Godot.

  • Хороша перша проблема: передбачається, що проблему легко виправити, тому вона чудово підходить для нових учасників, які хочуть ознайомитися з базою коду. Його слід видалити, поки доступний активний PR, який вирішує цю проблему.

  • Високий пріоритет: проблема особливо важлива, оскільки може перешкодити людям оприлюднити їхні проекти або спричинити втрату даних.

  • Потребує тестування: проблему/запит на вилучення не вдалося повністю перевірити, тому потребує подальшого тестування. Це може означати, що його потрібно перевірити на різних апаратних/програмних конфігураціях або навіть те, що кроки для відтворення не визначені.

  • Потрібна доопрацювання: запит на отримання потребує додаткової роботи, перш ніж його можна буде об’єднати. Також для проблем, які є дуже неповними, наприклад, відсутні кроки відтворення.

  • Продуктивність: проблеми, які безпосередньо впливають на роботу механізму або редактора. Також може використовуватися для запитів на витягування, які покращують продуктивність або додають зручні опції. Не має поєднуватися з Юзабіліті.

  • Регресія: помилка з’явилася після випуску стабільної версії, у якій не виявлено помилки.

  • 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 another 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.

  • Spam: intentional spam issues, and extremely low-effort PRs. Used sparingly, since we give contributors and users the benefit of the doubt. In most cases, Needs work or Archived is more appropriate.

  • Tracker: проблема, яка використовується для відстеження інших проблем (наприклад, усіх проблем, пов’язаних із системою плагінів).

  • Юзабіліті: проблеми, які безпосередньо впливають на зручність використання. Не слід поєднувати з продуктивністю.

The categories are used for general triage of the issues. They can be combined in some way when relevant, e.g. an issue can be labeled Bug and Usability at the same time if it's a bug that affects usability. Or Enhancement and Discussion if it's an improvement that requires discussion of the best approach. At least one of the categories Bug, Enhancement, or Discussion are used to describe an issue or pull request.

Topics:

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

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

  • Анімація: стосується системи анімації, редакторів та імпортерів.

  • Assetlib: стосується вад у бібліотеці asset.

  • Аудіо: стосується аудіофункцій (низький і високий рівень).

  • Buildsystem: стосується вад зі збиранням, пов'язаних або із системою збирання SCons, або із особливостями компілятора.

  • Стиль коду: стосується стилю програмування, який використовується в кодовій базі.

  • Core: усе, що стосується основного двигуна. Конкретні теми виділяються окремо в міру появи.

  • Dotnet: relates to the C# / .NET bindings.

  • Editor: стосується вад у редакторів (в основному, інтерфейсі користувача).

  • Експорт: відноситься до системи експорту та шаблонів.

  • GDExtension: відноситься до системи GDExtension для власних розширень.

  • GDScript: стосується GDScript.

  • GUI: стосується вузлів GUI (контролю) або вузлів, які складають інтерфейси користувача.

  • Імпорт: відноситься до системи імпорту ресурсів.

  • Введення: відноситься до системи введення.

  • I18n: relates to internationalization.

  • Багатокористувацька: відноситься до багатокористувацьких (мережевих систем високого рівня).

  • Навігація: відноситься до навігаційної системи (включаючи A* та навігаційні сітки).

  • Мережа: відноситься до (низького рівня) мережі.

  • Частинки: частинки, системи частинок та їх редактори.

  • Physics: стосується фізичного рушія (2D/3D).

  • Plugin: стосується проблем, з якими ви зіштовхнулися під час написання додатків.

  • Портування: стосується певних платформ або експортованих проектів.

  • Rendering: стосується рушіїв обробки плоского і просторового зображення.

  • Шейдери: відноситься до мови шейдерів Godot або візуальних шейдерів.

  • Тести: відноситься до модульних тестів.

  • Третя сторона: відноситься до сторонніх бібліотек, які використовуються в Godot.

  • XR: відноситься до доповненої реальності або віртуальної реальності.

Проблеми, як правило, стосуються лише однієї теми, хоча ймовірно побачити проблеми, які відповідають двом вимогам. Загальна ідея полягає в тому, що за всіма темами будуть спеціалізовані команди учасників, щоб вони могли зосередитися на проблемах, позначених темою їх команди.

Platforms:

Android, iOS, LinuxBSD, macOS, Web, Windows

За замовчуванням передбачається, що дана проблема стосується всіх платформ. Якщо використовується одна з міток платформи, вона є ексклюзивною, і попереднє припущення більше не діє (тому, якщо це помилка, наприклад, виключно для Android і Linux, виберіть ці дві платформи).

Ярлики документації

У репозиторії документації ми використовуємо наступні мітки:

  • Архівовано: або дублікат іншого випуску, або недійсний. Таке питання також буде закрито.

  • Помилка: Неправильна інформація на існуючій сторінці. Не використовувати для відсутньої інформації.

  • Cherrypick: описує щось, що може бути перенесено до стабільної гілки після об’єднання в гілку master.

  • Залежності: описує запити на отримання, які оновлюють файл залежностей.

  • Обговорення: питання не є консенсусним і потребує подальшого обговорення, щоб визначити, що саме слід зробити для вирішення теми.

  • Покращення: нова інформація буде додана на існуючу сторінку.

  • Хороша перша проблема: передбачається, що проблему легко виправити, тому вона чудово підходить для нових учасників, які хочуть ознайомитися з базою коду. Його слід видалити, поки доступний активний PR, який вирішує цю проблему.

  • Linked demo PR: the PR has a corresponding PR to the Godot Demo Projects repository which must be merged at the same time. Any changes to code in tutorials that have a corresponding demo, such as Ваша перша 2D гра, need to update both repositories so that the tutorial code stays in sync with the completed demo.

  • Потрібна доопрацювання: запит на отримання потребує додаткової роботи, перш ніж його можна буде об’єднати.

  • Python: Pull-запити, які оновлюють код Python.

  • Salvageable: запит на отримання не можна об’єднати через проблеми з дизайном або конфлікти злиття, а його автор більше не активний. Однак його все ще може підібрати зовнішній учасник, щоб привести його до стану зливання. Для цього вам потрібно відкрити новий запит на отримання на основі початкового запиту на отримання.

  • Tracker: проблема, яка використовується для відстеження інших проблем (наприклад, усіх проблем, пов’язаних із системою плагінів).

  • Waiting on PR merge: the PR documents an engine PR that has not been merged yet.

Area:

  • Про: проблеми та рекламні повідомлення, пов’язані з розділом «Про» документації та іншими загальними статтями.

  • Посилання на клас: проблема стосується посилання на клас, а не сторінки документації.

  • Спільнота: проблеми та рекламні повідомлення, пов’язані з розділом спільноти документації.

  • Внесок: Проблеми та PR, пов’язані з розділом Внесок/Розробка документації.

  • Початок роботи: Проблеми та PR, пов’язані з розділом документації «Початок роботи».

  • Посібник: проблеми та PR, пов’язані з розділом документації «Посібник/навчальні посібники».

Content:

  • Зображення: проблеми та рекламні оголошення, що стосуються застарілих або неправильних зображень у статтях.

  • Приклад коду: Проблеми та PR, пов’язані з написанням або оновленням прикладів коду.

  • Нова сторінка: проблеми та рекламні пропозиції, пов’язані зі створенням нових сторінок документації для нових або незадокументованих функцій.

  • Організація: Питання та PR, пов’язані з реорганізацією контенту.

  • Коректура: проблеми та запити, пов’язані з перевіркою документації.

  • Переадресація: проблеми та PR, пов’язані з переміщенням вмісту та додаванням правила переадресації на сервері.

  • Веб-сайт: проблеми, пов’язані з додаванням функцій веб-сайту та виправленням помилок, як на передній, так і на серверній частині,

Topic:

Доступні теми описують той самий вміст, що й теми в основному сховищі.

Віхи

Milestones are used for some issues and all PRs.

We have milestones for specific minor engine versions, like 4.5 and 4.6, as well as general milestones for major engine versions, like 3.x and 4.x. In the godot-proposals repo, we also have a 5.0 milestone for compatibility-breaking changes that will be considered for Godot 5.0, in many years.

Issues are assigned to the current development milestone, such as 4.5, if they are related to features introduced in that engine version, or are bugs (regressions) in that version. Additionally, all issues completed during the development of that engine version are added to the milestone, so that users can see at a glance in which minor version an issue was first fixed. We don't always use the 4.x milestone for issues, since by default all issues are related to Godot 4.x. However, we do use the 3.x milestone to mark issues that are specific to Godot 3.x.

All pull requests are assigned to a milestone. By default, enhancement and feature PRs are assigned to the 4.x milestone, and bugs are assigned to the current development milestone, such as 4.5. Towards the end of the minor version's development, PRs currently in that milestone are reassessed. If a PR is no longer being considered for that version, it is reassigned to either the major version milestone (4.x), or the next minor version milestone (such as 4.6).

Pull requests in the 4.x milestone are reassigned to the current minor engine version, such as 4.5, when the review process is complete, and the production team decides that the PR is ready to be merged soon. Note that this usually requires more than one approving review.

The milestone assigned to a PR is a goal, not a guarantee. New features and enhancements are merged when they are ready. While reviewers and maintainers do their best to review PRs in time for the current version, at some point we reach the beta, feature freeze, and then release; and existing PRs are reassigned to the next minor version, or to 4.x. As a rule, we assign new features to the 4.x milestone initially to avoid continually reassigning a PR from version to version. However, a PR being in 4.x does not mean it won't be merged; it's just the default for new features.