Richtlinien für die Fehlerbehebung

Diese Seite beschreibt den typischen Arbeitsablauf des Fehlerbeseitigungs-Teams (auch bekannt als Bugsquad) bei der Behandlung von Problemen und beim Abrufen von Anforderungen im Godot-Repository GitHub. Es muss sich zusammen mit dem Bugsquad weiterentwickeln. Zögern Sie also nicht, Änderungen an den folgenden Richtlinien vorzuschlagen.

Problem-Management

GitHub bietet verschiedene Funktionen zum Verwalten von Problemen an:

  • Setzen Sie einen oder mehrere Marker (Labels) aus einer vordefinierten Liste

  • Setzen Sie einen Meilenstein aus einer vordefinierten Liste

  • Verfolgen Sie das Problem im Projekt-Dashboard

  • Ernennen Sie einen Mitwirkenden zum "Zuständigen" unter den Mitgliedern der Godot Engine-Organisation

Da die Godot-Engine-Organisation auf GitHub derzeit nur eine begrenzte Anzahl von Mitwirkenden hat, werden momentan nur wenige Zuständigen benötigt. Alle Mitwirkenden können sich jedes Problems annehmen, wenn dies relevant ist, nachdem sie es auf dem Problemticket erwähnt und/oder mit anderen Entwicklern besprochen haben, wie es am besten gelöst werden kann.

Derzeit verwenden wir auch nicht die Projekt-Dashboard-Funktion.

Wir versuchen so weit wie möglich, sowohl Problemen als auch Pull-Anfragen Labels zuzuweisen (und gegebenenfalls Meilensteine).

Marker (Labels)

Die folgenden Bezeichnungen sind derzeit im Godot-Repository definiert:

Kategorien:

  • Archived: entweder ein Duplikat eines anderen Problems oder ungültig. Ein solches Problem wäre ebenfalls geschlossen.

  • Bug: beschreibt etwas, das nicht richtig funktioniert.

  • Confirmed: wurde von mindestens einem anderen Mitwirkenden als dem Fehler-Reporter bestätigt (normalerweise für Fehler-Berichte). Dieses Label soll Entwickler zeigen (bei der Auswahl woran sie arbeiten möchten) welche Probleme noch reproduzierbar sind. Es ist daher eine gute Praxis in einem Kommentar hinzuzufügen, auf welcher Plattform und in welcher Version oder in welchem Version von Godot das Problem reproduziert werden könnte. Wenn sich ein Entwickler ein Jahr später mit dem Problem befasst, ist der Marker Bestätigt möglicherweise nicht mehr relevant.

  • Discussion: Das Problem ist nicht einvernehmlich und bedarf weiterer Diskussion, um zu definieren, was genau getan werden soll, um das Thema anzugehen.

  • Documentation: Problem im Zusammenhang mit der Dokumentation, hauptsächlich, um Verbesserungen in der API-Dokumentation anzufordern. Probleme im Zusammenhang mit der ReadTheDocs-Dokumentation sollten im godot-docs Repository abgelegt werden.

  • Enhancement: Beschreibt eine vorgeschlagene Erweiterung einer vorhandenen Funktionalität.

  • Feature proposal: beschreibt den Wunsch nach Implementierung einer neuen Funktion.

  • Junior job: Es wird angenommen, dass das Problem leicht zu beheben ist, was es ideal für Junior-Mitwirkende macht, die sich mit der Codebasis vertraut machen müssen.

  • Needs rebase: Für das Problem muss eine Git-Rebase zusammengeführt werden.

  • Needs testing: Die Problem/Pull-Anforderung konnte nicht vollständig getestet werden und bedarf somit weiterer Tests. Dies kann bedeuten, dass es auf verschiedenen Hardware-/Softwarekonfigurationen getestet werden muss oder dass die zu reproduzierenden Schritte nicht sicher sind.

  • PR welcome / hero wanted!: Beiträge für Probleme mit diesen Labels sind besonders willkommen. Beachten Sie, dass dies nicht bedeutet, dass Sie ohne diese Beschriftungen nicht an Problemen arbeiten können.

  • Tracker: Problem das verwendet wird, um andere Probleme zu verfolgen (wie alle Probleme im Zusammenhang mit dem Plugin-System).

  • Usability: Probleme, die sich direkt auf die Benutzerfreundlichkeit auswirken.

Die Kategorien werden für die allgemeine Analyse der Probleme verwendet. Sie können auf irgendeine Weise kombiniert werden, wenn dies relevant ist, z.B. ein Problem kann gleichzeitig als Enhancement und Usability bezeichnet werden, wenn es sich um ein Problem zur Verbesserung der Benutzerfreundlichkeit handelt. Oder Feature proposal und Discussion, wenn es sich um eine nicht einvernehmliche Funktionsanforderung handelt oder wenn diese nicht präzise genug ist, um bearbeitet zu werden.

Themen:

  • Assetlib: Bezieht sich auf Probleme mit der Bestandsbibliothek.

  • Audio: bezieht sich auf die Audiofunktionen (niedriger und hoher Stufe).

  • Buildsystem: bezieht sich auf Build-Probleme, die entweder mit dem SCons-Buildsystem oder mit den Besonderheiten des Compilers zusammenhängen.

  • Core: alles, was mit der Haupt-Engine zu tun hat. Es könnte später weiter aufgeteilt werden, da es ein ziemlich großes Thema ist.

  • Drivers: bezieht sich auf Probleme mit den von der Engine verwendeten Treibern.

  • Editor: bezieht sich auf Probleme im Editor (hauptsächlich UI).

  • GDNative: bezieht sich auf das GDNative-Modul.

  • GDScript: bezieht sich auf GDScript.

  • Mono: bezieht sich auf C# / Mono Bindings.

  • Network: bezieht sich auf Networking.

  • Physics: bezieht sich auf die Physik Engine (2D/3D).

  • Plugin: bezieht sich auf Probleme beim Schreiben von Plugins.

  • Porting: bezieht sich auf einige spezielle Plattformen.

  • Rendering: bezieht sich auf die 2D und 3D Rendering Engine.

  • VisualScript: bezieht sich auf Probleme mit der visuellen Skriptsprache.

Probleme entsprechen normalerweise nur einem Thema, obwohl es nicht undenkbar ist, Probleme zu sehen, die zu zwei Themen passen. Die allgemeine Idee ist, dass hinter allen Themen spezialisierte Mitarbeiterteams stehen, damit sie sich auf die Themen konzentrieren können, die mit dem Thema ihres Teams gekennzeichnet sind.

Plattformen:

Android, HTML5, iOS, Linux, MacOS, Windows, UWP

Standardmäßig wird davon ausgegangen, dass ein bestimmtes Problem für alle Plattformen gilt. Wenn eines der Plattform-Labels verwendet wird, ist es exklusiv und die vorherige Annahme gilt nicht mehr (wenn es sich also ausschließlich um einen Fehler unter Android und Linux handelt, wählen Sie diese beiden Plattformen aus).

Meilensteine

Meilensteine entsprechen geplanten zukünftigen Versionen von Godot, für die es eine bestehende Roadmap gibt. Probleme, die in diese Roadmap passen, sollten unter dem entsprechenden Meilenstein eingereicht werden. Wenn sie keiner aktuellen Roadmap entsprechen, sollten sie ohne Meilenstein bleiben. Als Faustregel gilt, dass ein Problem einem bestimmten Meilenstein entspricht, wenn es sich um eine Funktion handelt, die neu im Meilenstein ist, oder um einen kritischen Fehler, der in einer zukünftigen stabilen Version nicht akzeptiert werden kann, oder um etwas, an dem Juan richtig arbeiten möchte jetzt. :)

Es steht den Mitwirkenden frei, Probleme unabhängig von ihrem zugewiesenen Meilenstein auszuwählen. Wenn ein Fix für einen Fehler vorgeschlagen wird, der nicht als dringend und damit ohne Meilenstein eingestuft wurde, wäre er wahrscheinlich immer noch sehr willkommen.