Lignes directrices pour le triage des bogues

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.

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.

For the time being, we do not use the project dashboard feature either.

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 :

  • Archivé : soit un double d'un autre numéro, soit non valable. Une telle issue serait également fermé.

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

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

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

  • 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: 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 : le problème est présumé être facile à résoudre, ce qui en fait un outil idéal pour les jeunes contributeurs qui doivent se familiariser avec la base de code.

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

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

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

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

Les catégories sont utilisées pour le triage des issues. Ils peuvent être combinés, d'une certaine façon, lorsque cela est pertinent, par exemple, un problème peut être étiqueté Enhancement et Usability en même temps, si c'est une issue pour améliorer la facilité d'utilisation. Ou Feature Proposal et de Discussion si c'est une demande de fonctionnalités dont l'implémentation doit être discutée, ou une qui n'est pas assez précise pour être implémenté.

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.

  • 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: relates to the programming style used within the codebase.

  • Core : tout ce qui est lié au cœur du moteur. Il pourrait être divisé en plusieurs labels plus tard, car c'est un sujet assez vaste.

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

  • GDNative : concerne le module GDNative.

  • GDScript : se rapporte au GDScript.

  • GUI: relates to GUI (Control) nodes.

  • Import: relates to the resource import system.

  • Input: relates to input system.

  • Mono : concerne les liaisons C# / Mono.

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

  • Network : se rapporte aux problème de mise en réseau.

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

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

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

  • Rendering : concerne les moteurs de rendu 2D et 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.

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.

Platforms :

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

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

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

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

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