Up to date

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

Lignes directrices pour le triage des bogues

Cette page décrit le flux de travail typique de l'équipe de triage des bogues alias bugsquad lors de la gestion des problèmes et des pull requests sur le dépôt GitHub de Godot. Elle est appelée à évoluer avec le bugsquad, n'hésitez donc pas à proposer des modifications aux directives suivantes.

Gestion des Issues

GitHub propose différentes fonctionnalités pour gérer les issues :

  • Définir un ou plusieurs labels à partir d'une liste prédéfinie

  • Poser un "milestone" à partir d'une liste prédéfinie

  • Suivez l'évolution de l'issue dans le tableau de bord du projet

  • Définir un contributeur comme "assignee" parmi les membres de l'organisation du moteur Godot

Comme l'organisation du moteur Godot sur GitHub a actuellement un nombre restreint de contributeurs, nous n'utilisons pas beaucoup de cessionnaires pour l'instant. Tous les contributeurs sont les bienvenus pour prendre en charge tout problème, le cas échéant après l'avoir mentionné sur le ticket de problème et/ou avoir discuté de la meilleure façon de le résoudre avec d'autres développeurs.

Pour l'instant, nous n'utilisons pas non plus la fonction de tableau de bord du projet.

Dans la mesure du possible, nous essayons d'attribuer des étiquettes (et des "milestones" le cas échéant) aux deux questions et aux demandes de retrait.

Labels

Les labels suivants sont actuellement définis dans le dépôt Godot :

Catégories :

  • Archived : soit un doublon d'un autre problème, soit n'est pas valable. Une telle issue serait également fermé.

  • Breaks compat : décris quelque chose qui ne peut être corrigé qu'en n'étant plus compatible avec les projets existants.

  • Bug : décrit quelque chose qui ne fonctionne pas correctement.

  • Cherrypick : décris quelque chose qui peut être repris de la branche master (principale) pour être intégrée dans la branche stable actuelle.

  • Confirmed : a été confirmée par au moins un autre contributeur que le rapporteur de bogue (généralement pour les rapports de bogue). L'objectif de ce label est de faire savoir aux développeurs quels problèmes sont encore reproductibles lorsqu'ils veulent choisir sur quoi travailler. C'est donc une bonne pratique que d'ajouter un commentaire sur la plate-forme et la version ou le commit de Godot sur lesquels le problème pourrait être reproduit ; si un développeur examine le problème un an plus tard, le label Confirmed peut ne plus être pertinent.

  • Crash : decris un bogue faisant planter le moteur de jeu. N'est utilisé que quand l'application quitte inopinément, et pas quand elle ne fait que se figer.

  • Discussion : la question n'est pas consensuelle et nécessite une discussion plus approfondie afin de définir ce qui doit être fait exactement pour traiter le sujet.

  • Documentation : question liée à la documentation. Principalement pour demander des améliorations dans la documentation de l'API. Les problèmes liés à la documentation de ReadTheDocs doivent être classés dans le dépôt godot-docs.

  • Enhancement : décrit une proposition d'amélioration d'une fonctionnalité existante.

  • Feature proposal : décrit un souhait de mise en œuvre d'une nouvelle fonctionnalité. Notez que le dépôt principal de Godot n'accepte plus les demandes de fonctionnalités. Veuillez utiliser godot-proposals à la place.

  • For PR meeting : le problème doit être discuté dans une réunion de pull request. Ces réunions sont publiques et se tiennent sur le Godot Contributors Chat.

  • Good first issue: the issue is assumed to be an easy one to fix, which makes it a great fit for new contributors who want to become familiar with the code base. It should be removed while an active PR is available, that resolves this issue.

  • High priority : ce problème a une _haut priorité_ car elle peut empêcher de publier des projets ou la perte de données.

  • Needs testing : l'issue ou la Pull Request n'a pas pu être complètement testée et doit donc être soumise à des tests supplémentaires. Cela peut signifier qu'elle doit être testée sur différentes configurations matérielles/logicielles ou même que les étapes à reproduire ne sont pas certaines.

  • Needs work : la pull request nécessite un travail supplémentaire avant de pouvoir être fusionnée.

  • Performance : problèmes qui ont un impact direct sur les performances du moteur ou de l'éditeur. Peut également être utilisé pour les demandes de pull qui améliorent les performances ou ajoutent des options conviviales pour le bas de gamme. Ne devrait pas être couplé avec Usability.

  • Production: Relates to the production team.

  • Régression : le bug est apparu après la publication d'une version stable ne présentant pas de bug.

  • Salvageable : la pull request ne peut pas être fusionnée en raison de problèmes de conception ou de conflits de fusion et son auteur n'est plus actif. Cependant, elle peut toujours être reprise par un contributeur externe pour la rendre fusionnable. Pour ce faire, vous devez ouvrir une nouvelle demande de pull request basée sur la demande originale.

  • Tracker : issue utilisé pour suivre d'autres problèmes (comme tous les problèmes liés au système de plugin).

  • Utilisabilité : questions qui ont un impact direct sur la convivialité pour l'utilisateur. Ne devrait pas être couplé avec Performance.

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 labelled Enhancement and Usability at the same time if it's an issue to improve usability. Or Feature proposal and Discussion if it's a non-consensual feature request, or one that is not precise enough to be worked on. At least one of the categories Bug, Enhancement or Discussion is used to describe an issue or pull request.

Topics :

  • 2D : concerne les questions spécifiques à la 2D. Doit être couplé avec l'une des étiquettes ci-dessous, et ne doit pas être couplé avec 3D.

  • 3D : concerne les questions spécifiques à la 3D. Doit être associé à l'une des étiquettes ci-dessous, et ne doit pas être associé à 2D.

  • Animation: relates to the Animation system, editors and importers.

  • Assetlib : concerne les questions relatives à la bibliothèque d'asset.

  • Audio : concerne les fonctions audio (haut et bas niveau).

  • Buildsystem : concerne les problèmes de compilation, soit liés au système de compilation SCons, soit aux particularités du compilateur.

  • Codestyle : concerne le style de programmation utilisé dans la base de code.

  • Core: anything related to the core engine. Specific topics are split off separately as they crop up.

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

  • Editor : concerne les issues de l'éditeur (principalement l'interface utilisateur).

  • Export: relates to the export system and templates.

  • GDExtension: relates to the GDExtension system for native extensions.

  • GDScript : se rapporte au GDScript.

  • GUI: relates to GUI (Control) nodes or to Nodes that compose user interfaces.

  • Import : concerne le système d'importation des ressources.

  • Input: relates to the input system.

  • Multiplayer: relates to multiplayer (high-level networking) systems.

  • Navigation : concerne le système de navigation (comme A* et les navmesh).

  • Network: relates to (lot-level) networking.

  • Particles: particles, particle systems and their editors.

  • Physics : concerne le moteur physique (2D/3D).

  • Plugin : concerne les problèmes rencontrés lors de l'écriture de plugins.

  • Porting : concerne certaines plateformes spécifiques ou projets d'exportation.

  • Rendering : concerne les moteurs de rendu 2D et 3D.

  • Shaders : concerne le langage de shader de Godot, ou les shaders visuels.

  • Tests : concerne les tests unitaires.

  • Thirdparty : concerne les bibliothèques tiers dans Godot.

  • XR : concerne la Réalité Augmentée (AR) ou la Réalité Virtuelle (VR).

Les Issues ne correspondent généralement qu'à un seul sujet, bien qu'il ne soit pas impensable d'en voir qui puissent concerner deux sujets. L'idée est qu'il y aura des équipes de contributeurs spécialisés derrière tous les sujets, afin qu'ils puissent se concentrer sur les questions étiquetées avec le sujet de leur équipe.

Plateformes :

Android, iOS, Linux, macOS, Web, Windows

Par défaut, on suppose qu'une issue donnée s'applique à toutes les plateformes. Si l'une des étiquettes de plate-forme est utilisée, elle est alors exclusive et l'hypothèse précédente ne tient plus (donc si c'est un bug sur par exemple Android et Linux exclusivement, sélectionnez ces deux plates-formes).

Labels de documentation

Dans le documentation repository, nous utilisons les étiquettes suivantes :

  • Archived : soit un doublon d'un autre problème, soit n'est pas valable. Une telle issue serait également fermé.

  • Bug : Information incorrecte dans une page existante. Ne doit pas être utilisé pour les informations manquantes.

  • Cherrypick : décris quelque chose qui peut être repris de la branche master (principale) pour être intégrée dans la branche stable actuelle.

  • Dependencies: describes pull requests that update a dependency file.

  • Discussion : la question n'est pas consensuelle et nécessite une discussion plus approfondie afin de définir ce qui doit être fait exactement pour traiter le sujet.

  • Enhancememnt : nouvelle information à ajouter dans une page existante.

  • Good first issue: the issue is assumed to be an easy one to fix, which makes it a great fit for new contributors who want to become familiar with the code base. It should be removed while an active PR is available, that resolves this issue.

  • Needs work : la pull request nécessite un travail supplémentaire avant de pouvoir être fusionnée.

  • Python: Pull requests that update Python code.

  • Salvageable : la pull request ne peut pas être fusionnée en raison de problèmes de conception ou de conflits de fusion et son auteur n'est plus actif. Cependant, elle peut toujours être reprise par un contributeur externe pour la rendre fusionnable. Pour ce faire, vous devez ouvrir une nouvelle demande de pull request basée sur la demande originale.

  • Tracker : issue utilisé pour suivre d'autres problèmes (comme tous les problèmes liés au système de plugin).

Area:

  • About: Issues and PRs related to the About section of the documentation and other general articles.

  • Class reference : le problème concerne la référence de la classe, et non une page de documentation.

  • Community: Issues and PRs related to the Community section of the documentation.

  • Contributing: Issues and PRs related to the Contributing/Development section of the documentation.

  • Getting started: Issues and PRs related to the Getting Started section of the documentation.

  • Manual: Issues and PRs related to the Manual/Tutorials section of the documentation.

Content:

  • Images: Issues and PRs involving outdated or incorrect images in articles.

  • New page: Issues and PRs related to creation of new documentation pages for new or undocumented features.

  • Organization: Issues and PRs related to reorganizing the content.

  • Proofreading: Issues and PRs related to proofreading the documentation.

  • Redirect: Issues and PRs involving moving content and adding a redirect rule on the backend.

  • Website: Issues related to adding website features and fixing bugs, whether on the front or back-end,

Topic:

The available topics describe the same content as the topics in the main repository.

Étapes

Les Milestones (Jalon) correspondent aux futures versions de Godot prévues pour lesquelles il existe une feuille de route. Les questions qui s'inscrivent dans ladite feuille de route doivent être classées dans la milestone correspondante ; si elles ne correspondent à aucune feuille de route actuelle, elles doivent être laissées hors de toute milestone. En règle générale, un problème correspond à une milestone donnée s'il concerne une nouvelle fonctionnalité de la milestone, ou un bogue critique qui ne peut être accepté dans une future version stable, ou tout ce sur quoi Juan veut travailler maintenant :)

Les contributeurs sont libres de choisir les problèmes indépendamment du jalon qui leur est attribué ; si une correction est proposée pour un bogue qui n'a pas été jugé urgent et donc sans milestone, elle sera probablement toujours la bienvenue.