Wytyczne dotyczące usuwania błędów

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.

Zarządzanie problemami

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.

Labels(Etykiety)

Następujące etykiety są obecnie zdefiniowane w repozytorium Godota:

Kategorie:

  • Archived: opisuje duplikaty innych zgłoszeń błędów, lub jest niepoprawny. Może zostać zamknięty.

  • Breaks compat: describes something that can only be fixed by breaking compatibility with existing projects.

  • Bug: opisuje coś, co nie działa poprawnie.

  • Cherrypick: describes something that can be backported to a stable branch after being merged in the master branch.

  • Crash: describes a bug that causes the engine to crash. This label is only used for "hard" crashes, not freezes.

  • Confirmed: został potwierdzony przez co najmniej jednego użytkownika niż zgłaszający błąd . Celem tej etykiety jest poinformowanie programistów, które problemy są możliwe do odtworzenia, aby móc łatwo znaleźć błąd i jego przyczynę. Dlatego też dobrą praktyką jest dodanie w komentarzu, na jakiej platformie i w jakiej wersji Godota(również nieoficjalnych) sprawa ta mogłaby zostać powielona; jeśli deweloper rozpatrzy problem dopiero rok później, oznaczenie Confirmed może już nie mieć znaczenia.

  • Discussion: kwestia ta nie jest jednomyślna i wymaga dalszych dyskusji w celu określenia, co dokładnie należy zrobić, aby dojść do rozwiązania problemu lub dojścia do kompromisu.

  • Documentation: problem związany z dokumentacją. Stworzony głównie po to, aby ukazać potrzebę ulepszeń w dokumentacji API. Zagadnienia związane z dokumentacją ReadTheDocs należy zgłaszać w repozytorium godot-docs.

  • Enhancement: opisuje proponowane rozszerzenie istniejącej funkcjonalności.

  • Feature proposal: describes a wish for a new feature to be implemented. Note that the main Godot repository no longer accepts feature requests. Please use godot-proposals instead.

  • For PR meeting: the issue needs to be discussed in a pull request meeting. These meetings are public and are held on the Godot Contributors Chat.

  • Junior job: problem jest uważany za łatwy do rozwiązania, co sprawia, że doskonale nadaje się dla młodszych współkoderów, którzy muszą zapoznać się z kodem.

  • High priority: the issue is particularly important as it can prevent people from releasing their projects or cause data loss.

  • Needs work: the pull request needs additional work before it can be merged.

  • Needs testing: Zgłoszenie błędu/Pull Request potrzebuje testów by wyeliminować problemy. Może to oznaczać, że musi być przetestowany na różnych konfiguracjach sprzętu/oprogramowania lub nawet, że kroki do odtworzenia określonych zachowań nie są pewne.

  • 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: Zgłoszenie problemu który służy do śledzenia powiązanych ze sobą problemów lub pull requestów(np. związanych z systemem rozszerzeń).

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

Kategorie te są stosowane w odniesieniu do ogólnego oceny zagadnień. W razie potrzeby można je w pewien sposób łączyć, np. problem można oznaczyć Enhancement i Uability jednocześnie, jeśli chodzi o poprawę użyteczności. Lub Feature proposal i Discussion, jeśli jest to zgłoszenie dotyczące funkcji które mogą być dla niektórych inaczej stworzone lub niepotrzebne.

Tematy:

  • 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: odnosi się do kwestii związanych z biblioteką zasobów.

  • Audio:odnosi się do dźwięku (zarówno wysoko jak i niskopoziomowego API).

  • Buildsystem: odnosi się do problemów z budowaniem programu, połączeniem z SCons i kompilacją.

  • Codestyle: relates to the programming style used within the codebase.

  • Core: odnosi się do rdzenia silnika. Może zostać podzielony, ponieważ to bardzo duży temat.

  • Editor: odnosi się do edytora (głównie UI).

  • GDNative: odnosi się do modułu GDNative.

  • GDScript: odnosi się do GDScript.

  • GUI: relates to GUI (Control) nodes.

  • Import: relates to the resource import system.

  • Input: relates to input system.

  • Mono: odnosi się do C# / Mono.

  • Navigation: relates to the navigation system (including A* and navmeshes).

  • Network: odnosi się do sieci.

  • Physics: odnosi się do silnika fizyki (2D/3D).

  • Plugin: odnosi się do problemów z pisaniem wtyczek.

  • Porting: relates to some specific platforms or exporting projects.

  • Rendering: odnosi się do błędów renderowania silnika 2D i 3D.

  • Shaders: relates to the Godot shader language or visual shaders.

  • Tests: relates to unit tests.

  • Thirdparty: relates to third-party libraries used in Godot.

  • VisualScript: relates to issues with the visual scripting language (not visual shaders).

  • XR: relates to Augmented Reality or Virtual Reality.

Issues would typically correspond to only one topic, though it's not unthinkable to see issues that fit two bills. The general idea is that there will be specialized contributors teams behind all topics, so they can focus on the issues labelled with their team's topic.

Platformy:

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

By default, it is assumed that a given issue applies to all platforms. If one of the platform labels is used, it is then exclusive and the previous assumption doesn't stand anymore (so if it's a bug on e.g. Android and Linux exclusively, select those two platforms).

Documentation labels

In the documentation repository, we use the following labels:

  • Bug: Incorrect information in an existing page. Not to be used for missing information.

  • Class reference: the issue is about the class reference, not a documentation page.

  • Discussion: kwestia ta nie jest jednomyślna i wymaga dalszych dyskusji w celu określenia, co dokładnie należy zrobić, aby dojść do rozwiązania problemu lub dojścia do kompromisu.

  • Enhancememnt: new information to be added in an existing page.

  • New page: a new page to be created.

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

  • Organization: The issue involves moving pages around or reorganizing content.

  • Redirect: a redirection needs to be created in the Read the Docs backend. Only administrators can do this.

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

  • Topic:Mono: the issue is about C# support in Godot.

  • Topic:Website: the issue relates to the Sphinx/Read the Docs frontend or backend, not the documentation contents.

Kamienie Milowe

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. :)

Contributors are free to pick issues regardless of their assigned milestone; if a fix is proposed for a bug that was not deemed urgent and thus without milestone, it would likely still be very welcome.