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.
  • Bug: opisuje coś, co nie działa poprawnie.
  • 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: opisuje prośbę wdrożenia nowej funkcji.
  • 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.
  • Needs rebase: potrzebuje aktualizacji kodu - poprzez możliwe konflikty z innymi jego kawałkami.
  • 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.
  • PR welcome / hero wanted!: Szczególnie mile widziane są uwagi dotyczące kwestii związanych z tymi znacznikami. Zauważ, że to nie oznacza, że nie możesz pracować nad problemami bez tych etykiet.
  • 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: kwestie, które mają bezpośredni wpływ na użyteczność użytkownika.

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:

  • 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ą.
  • Core: odnosi się do rdzenia silnika. Może zostać podzielony, ponieważ to bardzo duży temat.
  • Drivers: odnosi się do sterowników używanych przez silnik.
  • Editor: odnosi się do edytora (głównie UI).
  • GDNative: odnosi się do modułu GDNative.
  • GDScript: odnosi się do GDScript.
  • Mono: odnosi się do C# / Mono.
  • Network: odnosi się do sieci.
  • Physics: odnosi się do silnika fizyki (2D/3D).
  • Plugin: odnosi się do problemów z pisaniem wtyczek.
  • Porting: odnosi się do specyfiki danej platformy.
  • Rendering: odnosi się do błędów renderowania silnika 2D i 3D.
  • VisualScript: odnosi się do błędów z językiem Visual Script.

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

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.