Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

Richtlinien für die Bug-Behebung¶

Diese Seite beschreibt den typischen Workflow des Bug-Analyse-Teams, auch Bugsquad genannt, bei der Bearbeitung von Problemen und Pull Requests auf Godots GitHub Repository. Sie wird sich zusammen mit dem Bugsquad weiterentwickeln - zögern Sie also nicht, Änderungen an den folgenden Richtlinien vorzuschlagen.

Issue-Management¶

GitHub bietet verschiedene Features zum Verwalten von Issues an:

Setzen eines oder mehrerer Labels aus einer vordefinierten Liste
Setzen eines Milestones aus einer vordefinierten Liste
Verfolgen der Issue im Projekt-Dashboard
Ernennen eines Mitgliedern der Godot Engine-Organisation als "Assignee"

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

Auch das Feature des Projekt-Dashboards nutzen wir vorerst nicht.

Wir versuchen so weit wie möglich, sowohl Issues als auch Pull Requests Labels zuzuweisen (und gegebenenfalls Milestones).

Labels¶

Die folgenden Labels sind derzeit im Godot-Repository definiert:

Kategorien:

Archived: entweder ein Duplikat einer anderen Issue oder ungültig. Eine solche Issue würde ebenfalls geschlossen werden.
Breaks compat: beschreibt etwas, das nur behoben werden kann, indem die Kompatibilität mit bestehenden Projekten gebrochen wird.
Bug: beschreibt etwas, das nicht richtig funktioniert.
Cherrypick: beschreibt etwas, das in einen stable Branch zurückportiert werden kann, nachdem es in den master-Branch eingefügt wurde.
Confirmed: wurde durch mindestens einen anderen Mitwirkenden als den Bug-Reporter bestätigt (typischerweise für Bug-Reports). Der Zweck dieses Labels besteht darin, die Entwickler wissen zu lassen, welche Probleme noch reproduzierbar sind, wenn sie auswählen wollen, woran sie arbeiten sollen. Es ist daher gute Praxis, einen Kommentar hinzuzufügen, auf welcher Plattform und in welcher Version oder Commit von Godot die Issue reproduziert werden konnte; wenn ein Entwickler die Issue ein Jahr später betrachtet, ist das Label Confirmed möglicherweise nicht mehr relevant.
Crash: beschreibt einen Bug, der die Engine zum Absturz bringt. Dieses Label wird nur für "harte" Abstürze verwendet, nicht für Freezes.
Discussion: Das Problem ist nicht einstimmig bewertet 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 eingereicht werden.
Enhancement: Beschreibt eine vorgeschlagene Erweiterung einer vorhandenen Funktionalität.
Feature Proposal: beschreibt den Wunsch nach einem neuen Feature, das implementiert werden soll. Beachten Sie, dass das Godot-Hauptrepository keine Feature Requests mehr annimmt. Bitte verwenden Sie stattdessen godot-proposals.
For PR meeting: Das Problem muss in einem Pull Request-Meeting diskutiert werden. Diese Treffen sind öffentlich und werden im Godot-Mitwirkenden-Chat abgehalten.
Good first issue: Es wird angenommen, dass das Problem einfach zu beheben ist, was es für neue Mitwirkende, die sich mit der Codebasis vertraut machen wollen, sehr gut geeignet macht. Es sollte entfernt werden, solange ein aktiver PR verfügbar ist, der dieses Problem behebt.
High Priority: Das Problem ist besonders wichtig, da es Menschen daran hindern kann, ihre Projekte zu releasen, oder da es zu Datenverlust führen kann.
Needs testing: Die Issue oder der Pull Request 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 klar sind.
Needs work: Der Pull Request benötigt zusätzliche Arbeit, bevor er gemergt werden kann.
Performance: Issues, die sich direkt auf die Performance der Engine oder des Editors auswirken. Kann auch für Pull Requests verwendet werden, die Godots Performance verbessern oder die Optionen für Low-End-Geräte hinzufügen. Sollte nicht gemeinsam mit Usability verwendet werden.
Production: Bezieht sich auf das Produktionsteam.
Regression: Der Bug trat auf, nachdem eine stable Version veröffentlicht wurde, die den Bug nicht aufwies.
Salvageable: der Pull Request kann aufgrund von Designproblemen oder Merge-Konflikten nicht gemergt werden und sein Autor ist nicht mehr aktiv. Sie kann jedoch immer noch von einem externen Mitwirkenden aufgegriffen werden, um sie in einen merge-fähigen Zustand zu bringen. Um dies zu tun, müssen Sie einen neuen Pull Request öffnen, der auf dem ursprünglichen Pull Request basiert.
Tracker: Issue, die verwendet wird, um andere Issues zu tracken (wie etwa alle Probleme im Zusammenhang mit dem Plugin-System).
Usability: Fragen, die sich direkt auf die Benutzerfreundlichkeit auswirken. Sollte nicht gemeinsam mit Performance verwendet werden.

Die Kategorien werden für die allgemeine Einteilung der Probleme verwendet. Sie können bei Bedarf kombiniert werden, z.B. kann ein Problem 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 ein Feature-Request ohne einstimmige Bewertung handelt, oder eine, die nicht präzise genug ist, um bearbeitet zu werden. Mindestens eine der Kategorien Bug, Enhancement oder Discussion wird verwendet, um eine Issue oder einen Pull Request zu beschreiben.

Themen:

2D: bezieht sich auf 2D-spezifische Issues. Sollte gemeinsam mit einem der nachstehenden Labels verwendet werden und nicht mit 3D.
3D: bezieht sich auf 3D-spezifische Issues. Sollte gemeinsam mit einem der nachstehenden Labels verwendet werden und nicht mit 2D.
Animation: bezieht sich auf das Animationssystem, die Editoren und Importer.
Assetlib: Bezieht sich auf Probleme mit der Asset-Bibliothek.
Audio: bezieht sich auf die Audio-Features (Low-Level und High-Level).
Buildsystem: bezieht sich auf Build-Issues, die entweder mit dem SCons-Buildsystem oder mit den Besonderheiten des Compilers zusammenhängen.
Codestyle: bezieht sich auf den in der Codebasis verwendeten Programmierstil.
Core: alles, was mit der Kern-Engine zu tun hat. Spezifische Themen werden separat behandelt, wenn sie auftauchen.
Dotnet: bezieht sich auf die C#/Dotnet-Bindings.
Editor: bezieht sich auf Probleme im Editor (hauptsächlich UI).
Export: bezieht sich auf das Exportsystem und die Export-Vorlagen.
GDExtension: bezieht sich auf das GDExtension-System für native Erweiterungen.
GDScript: bezieht sich auf GDScript.
GUI: bezieht sich auf GUI (Control)-Nodes oder auf Nodes zur Erstellung von Benutzeroberflächen.
Import: bezieht sich auf das System für den Import von Ressourcen.
Input: bezieht sich auf das Eingabesystem.
Multiplayer: bezieht sich auf Multiplayer-Systeme (High-Level-Networking).
Navigation: bezieht sich auf das Navigationssystem (einschließlich A* und Navmeshes).
Network: bezieht sich auf (Lot-Level) Netzwerke.
Particles: Partikel, Partikelsysteme und ihre Editoren.
Physics: bezieht sich auf die Physik-Engine (2D/3D).
Plugin: bezieht sich auf Probleme beim Schreiben von Plugins.
Porting: bezieht sich auf bestimmte Plattformen oder den Export von Projekten.
Rendering: bezieht sich auf die 2D- und 3D-Rendering-Engine.
Shader: bezieht sich auf die Godot-Shader-Sprache oder visuelle Shader.
Tests: bezieht sich auf Unit-Tests.
Thirdparty: bezieht sich auf Bibliotheken von Drittanbietern, die in Godot verwendet werden.
XR: bezieht sich auf Augmented Reality oder Virtual Reality.

Issues werden in der Regel nur einem Thema entsprechen, obwohl es nicht undenkbar ist, dass Issues zu zwei Themen passen. Der Grundgedanke ist, dass es für alle Themen spezialisierte Teams gibt, so dass sie sich auf die Themen konzentrieren können, die mit dem Thema ihres Teams gekennzeichnet sind.

Plattformen:

Android, iOS, Linux, macOS, Web, Windows

Standardmäßig wird davon ausgegangen, dass eine bestimmte Issue 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 Bug unter Android und Linux handelt, wählen Sie diese beiden Plattformen aus).

Dokumentations-Labels¶

Im Dokumentations-Repository verwenden wir die folgenden Labels:

Archived: entweder ein Duplikat einer anderen Issue oder ungültig. Eine solche Issue würde ebenfalls geschlossen werden.
Bug: Falsche Informationen auf einer bestehenden Seite. Nicht zu verwenden für fehlende Informationen.
Cherrypick: beschreibt etwas, das in einen stable Branch zurückportiert werden kann, nachdem es in den master-Branch eingefügt wurde.
Dependencies: beschreibt Pull Requests, die eine Abhängigkeitsdatei aktualisieren.
Discussion: Das Problem ist nicht einstimmig bewertet und bedarf weiterer Diskussion, um zu definieren, was genau getan werden soll, um das Thema anzugehen.
Enhancement: neue Informationen, die einer bestehenden Seite hinzugefügt werden sollen.
Good first issue: Es wird angenommen, dass das Problem einfach zu beheben ist, was es für neue Mitwirkende, die sich mit der Codebasis vertraut machen wollen, sehr gut geeignet macht. Es sollte entfernt werden, solange ein aktiver PR verfügbar ist, der dieses Problem behebt.
Needs work: Der Pull Request benötigt zusätzliche Arbeit, bevor er gemergt werden kann.
Python: Pull Requests, die Python-Code aktualisieren.
Salvageable: der Pull Request kann aufgrund von Designproblemen oder Merge-Konflikten nicht gemergt werden und sein Autor ist nicht mehr aktiv. Sie kann jedoch immer noch von einem externen Mitwirkenden aufgegriffen werden, um sie in einen merge-fähigen Zustand zu bringen. Um dies zu tun, müssen Sie einen neuen Pull Request öffnen, der auf dem ursprünglichen Pull Request basiert.
Tracker: Issue, die verwendet wird, um andere Issues zu tracken (wie etwa alle Probleme im Zusammenhang mit dem Plugin-System).

Abschnitt:

About: Issues und PRs im Zusammenhang mit dem About-Abschnitt der Dokumentation und anderen allgemeinen Artikeln.
Class reference: Die Issue behandelt die Klassenreferenz, nicht eine Dokumentationsseite.
Community: Probleme und PRs, die sich auf den Community-Bereich der Dokumentation beziehen.
Contributing: Probleme und PRs, die sich auf den Abschnitt "Mitwirken/Engine-Entwicklung" der Dokumentation beziehen.
Getting started: Probleme und PRs im Zusammenhang mit dem Abschnitt "Erste Schritte" in der Dokumentation.
Manual: Probleme und PRs, die sich auf den Abschnitt "Handbuch" in der Dokumentation beziehen.

Inhalte:

Images: Probleme und PRs im Zusammenhang mit veralteten oder falschen Bildern in Artikeln.
New page: Probleme und PRs im Zusammenhang mit der Erstellung neuer Dokumentationsseiten für neue oder undokumentierte Features.
Organization: Probleme und PRs im Zusammenhang mit der Umstrukturierung der Dokumentation.
Proofreading: Probleme und PRs im Zusammenhang mit dem Korrekturlesen der Dokumentation.
Redirect: Issues und PRs, die das Verschieben von Inhalten und das Hinzufügen einer Umleitungsregel im Backend betreffen.
Website: Fragen im Zusammenhang mit dem Hinzufügen von Website-Features und der Behebung von Bugs, sowohl im Front- als auch im Backend.

Thema:

Die verfügbaren Themen beschreiben denselben Inhalt wie die Themen im Haupt-Repository.

Milestones¶

Milestones 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 Milestone eingereicht werden. Wenn sie keiner aktuellen Roadmap entsprechen, sollten sie ohne Milestone bleiben. Als Faustregel gilt, dass ein Problem einem bestimmten Milestone entspricht, wenn es sich um ein neues Feature in diesem Milestone handelt, oder um einen kritischen Bug, der in keinem zukünftigen stable Release akzeptiert werden kann, oder um etwas, an dem Juan gerade arbeiten möchte :)

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