Façons de contribuer

Le moteur Godot est un projet à but non lucratif, communautaire, libre et open source. Presque tous les développeurs (à l'exception de notre chef de file, Juan, dont vous trouverez plus de détails ci-dessous) travaillent pro bono sur leur temps libre, par intérêt personnel et pour l'amour de la création d'un moteur libre de qualité exceptionnelle.

Cela signifie que pour prospérer, Godot a besoin d'autant d'utilisateurs que possible s'impliquant en contribuant au moteur. Il existe de nombreuses façons de contribuer à un projet aussi important, permettant à chacun d'apporter quelque chose de positif au moteur, indépendamment de ses compétences :

  • Faire partie de la communauté. La meilleure façon de contribuer à Godot et de l'aider à devenir toujours meilleur est simplement d'utiliser le moteur et de le promouvoir de bouche à oreille, dans les crédits ou l'écran de démarrage de vos jeux, articles de blog, tutoriels, vidéos, démos, événements gamedev ou logiciels libres, support sur les Q&R, IRC, forums, Discord, etc. Participez ! Être un utilisateur et un promoteur aide à faire connaître notre formidable moteur, qui n'a pas de budget marketing et ne peut donc compter que sur sa communauté pour se diffuser.
  • Créez des jeux. Ce n'est un secret pour personne, pour convaincre les nouveaux utilisateurs et en particulier l'industrie dans son ensemble que Godot est un acteur pertinent du marché, nous avons besoin de grands jeux créés avec Godot. Nous savons que le moteur a beaucoup de potentiel, à la fois pour les jeux 2D et 3D, mais étant donné son jeune âge, nous manquons encore de grosses sorties qui attireront l'attention sur Godot. Alors continuez à travailler sur vos super projets, chaque nouveau jeu augmente notre crédibilité sur le marché du développement de jeu !
  • Impliquez-vous dans le développement du moteur. Cela peut être en contribuant au code via des pull requests, en testant les versions de développement ou directement la branche git master, en signalant les bugs ou en suggérant des améliorations sur le tracker de problème(issue), en améliorant la documentation officielle (la référence de classe et les tutoriels) et ses traductions. Les sections suivantes couvriront chacune de ces façons "directes" de contribuer au moteur.
  • Faire un don. Godot est un projet à but non lucratif, mais il peut quand même bénéficier de dons d'utilisateurs pour bien des choses. Outre les dépenses habituelles telles que les frais d'hébergement ou le matériel promotionnel lors d'événements, nous utilisons également l'argent des dons pour acquérir du matériel lorsque cela est nécessaire (par exemple, nous avons utilisé l'argent des dons pour acheter un MacBook Pro pour implémenter le support Retina / HiDPI et diverses autres fonctionnalités liées à macOS). Plus important encore, nous avons également utilisé l'argent des dons pour embaucher les développeurs principaux afin qu'ils puissent travailler à plein temps sur le moteur. Même avec un salaire mensuel bas, nous avons besoin d'un revenu de don stable pour continuer à le faire, ce qui a été très bénéfique pour le projet jusqu'à présent. Donc, si vous souhaitez donner de l'argent au projet, consultez notre site Web pour plus de détails.

Contribuer au code

La possibilité d'étudier, d'utiliser, de modifier et de redistribuer les modifications du code source du moteur sont les droits fondamentaux que la licence MIT de Godot vous accorde, le rendant gratuit et logiciel open source.

En tant que tel, tout le monde est autorisé à modifier le code source de Godot, et à envoyer ces modifications au projet en amont sous la forme d'un patch (un fichier texte décrivant les changements d'une manière prête à appliquer) ou - dans le flux de travail moderne que nous utilisons - via une "pull request" (PR), c'est-à-dire une proposition de fusionner directement un ou plusieurs commits Git (patches) dans la branche de développement principal.

Contribuer aux modifications de code en amont présente deux grands avantages :

  • Votre code sera examiné et amélioré par d'autres développeurs, et sera maintenu directement dans le projet en amont, vous n'aurez donc pas à réappliquer vos propres modifications chaque fois que vous passez à une version plus récente. D'un autre côté, cela implique une responsabilité, car vos modifications doivent être suffisamment génériques pour être utiles à tous les utilisateurs, et pas seulement à votre projet ; dans certains cas, il peut être pertinent de conserver vos modifications uniquement pour votre propre projet, si elles sont trop spécifiques.
  • Toute la communauté bénéficiera de votre travail, et les autres contributeurs se comporteront de la même manière, en contribuant du code qui vous sera bénéfique. Au moment d'écrire ces lignes, plus de 1000 développeurs ont apporté des modifications de code au moteur !

Pour assurer une bonne collaboration et qualité globale, les développeurs Godot appliquent certaines règles pour les contributions au code, par exemple concernant le style à utiliser dans le code C ++ (indentation, crochets, etc.) ou le flux de travail Git et PR.

Un bon point de départ est de rechercher les problèmes marqués comme junior jobs (ou Hacktoberfest en octobre) sur GitHub.

Voir aussi

Les détails techniques sur le workflow PR sont décrits dans une section spécifique, Flux de travail pour les Pull Request.

Les détails sur les directives de style de code et l'outil clang-format utilisé pour les appliquer sont décrits dans Lignes directrices pour le style du code.

Tester et signaler les problèmes (issues)

Une autre excellente façon de contribuer à le moteur est de tester les versions de développement ou la branche de développement et de signaler des problèmes. Il est également utile de signaler les problèmes découverts dans les versions stables, de sorte qu'ils puissent être fixés dans la branche de développement et dans les futures versions de maintenance.

Tester les versions de développement

Pour aider avec les tests, vous avez plusieurs possibilités :

  • Compilez le moteur à partir de la source vous-même, en suivant les instructions de la page Compiler pour votre plate-forme.
  • Tester les binaires officiels de pré-publication lorsqu'ils sont annoncés (généralement sur le blog et d'autres plates-formes communautaires), comme les compilations candidates alpha, bêta et release.
  • Tester les constructions officieuses « fiables » de la branche de développement ; il suffit de demander aux membres de la communauté des fournisseurs fiables. Dans la mesure du possible, il est préférable d’utiliser des binaires officiels ou de compiler vous même, pour être sûr de la provenance de vos binaires.

Comme mentionné précédemment, il est également utile de garder les yeux ouverts pour les bugs potentiels qui pourraient encore être présents dans les versions stables, en particulier lors de l'utilisation de certaines fonctionnalités niche du moteur qui pourraient être moins testées par les développeurs.

Signaler un problème(issue) sur GitHub

Godot utilise l'outil de suivi des problèmes de GitHub pour les rapports de bogues et les suggestions d'amélioration. Vous aurez besoin d'un compte GitHub pour pouvoir y ouvrir un nouveau problème, et cliquez sur le bouton "New issue".

Lorsque vous signalez un bug, vous devez garder à l'esprit que le processus est similaire à un rendez-vous avec votre médecin. Vous avez remarqué des symptômes qui vous font penser que quelque chose ne va pas (le moteur plante, certaines fonctionnalités ne réagissent pas comme prévu, etc). C'est le rôle de l'équipe de tri des bogues et des développeurs d'aider ensuite à faire le diagnostic du problème que vous avez rencontré, afin que la cause réelle puisse être identifiée et traitée.

Vous devez donc toujours vous demander : quelles sont les informations pertinentes à donner pour que les autres contributeurs à Godot puissent comprendre le bogue, l'identifier et le corriger. Voici quelques-unes des informations les plus importantes que vous devriez toujours fournir :

  • L'OS. Parfois, les bogues sont spécifiques au système opérationnel (OS), c'est-à-dire qu'ils se produisent uniquement sous Windows, ou uniquement sous Linux, etc. Cela est particulièrement vrai pour tous les bogues liés aux interfaces du système d'exploitation, comme la gestion des fichiers, des entrées, des fenêtres, de l'audio, etc.
  • Le matériel. Parfois, les bogues sont spécifiques au matériel, c'est-à-dire qu'ils ne se produisent que sur certains processeurs, cartes graphiques, etc. Si vous en êtes capable, il peut être utile d'inclure des informations sur votre matériel.
  • version de Godot. C'est un must. Certains problèmes peuvent être pertinents dans la version stable actuelle, mais corrigés dans la branche développement, ou l'inverse. Vous pouvez également utiliser une version obsolète de Godot et rencontrer un problème connu corrigé dans une version ultérieure, donc le savoir dès le début aide à accélérer le diagnostic.
  • Comment reproduire le bogue. Dans la majorité des cas, les bugs sont reproductibles, c'est-à-dire qu'il est possible de les déclencher de manière fiable en suivant certaines étapes. Veuillez toujours décrire ces étapes aussi clairement que possible, afin que chacun puisse essayer de reproduire le problème et le confirmer. Idéalement, faites un projet de démonstration qui reproduit ce problème à l'extérieur de la boîte, compressez-le et attachez-le au problème (vous pouvez faire cela par glisser-déposer). Même si vous pensez que le numéro est trivial à reproduire, l'ajout d'un projet minimal qui permet de le reproduire est une grande valeur ajoutée. Vous devez garder à l'esprit qu'il y a des milliers de numéros dans le tracker, et que les développeurs ne peuvent consacrer que peu de temps à chaque numéro.

Lorsque vous cliquez sur le bouton "New issue" (nouveau problème), une zone de texte pré-remplie avec notre modèle d'édition devrait vous être présentée. Veuillez essayer de le suivre afin que tous les numéros soient cohérents et fournissent les informations requises.

Contribuer à la documentation

Il existe deux ressources distinctes appelées "documentation" dans Godot :

  • La référence des classes C'est la documentation de l'API Godot complète, telle qu'elle est exposée au GDScript et aux autres langages de script. Elle peut être consultée hors ligne, directement dans l'éditeur de code de Godot, ou en ligne à l'adresse Godot API. Pour contribuer à la référence de classe, vous devez éditer le fichier doc/base/classes.xml dans le dépôt Git de Godot, et faire une pull request. Voir Contribuer à la référence des classes pour plus de détails.
  • Les tutoriels et la documentation du moteur et ses traductions. C'est la partie que vous êtes en train de lire, qui est distribuée aux formats HTML, PDF et EPUB. Son contenu est généré à partir de fichiers de texte brut au format texte restructuré (rst), auxquels vous pouvez contribuer par des requêtes pull sur le dépôt GitHub godot-docs. Voir Lignes directrices en matière de documentation pour plus de détails.

Contribuer aux traductions

Pour rendre Godot accessible à tous, y compris aux utilisateurs qui préfèrent les ressources dans leur langue maternelle plutôt qu'en anglais, notre communauté aide à traduire l'éditeur de Godot et sa documentation dans de nombreuses langues.

Voir Localisation de l'éditeur et de la documentation pour plus de détails.