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 :

  • Be part of the community. The best way to contribute to Godot and help it become ever better is simply to use the engine and promote it by word-of-mouth, in the credits or splash screen of your games, blog posts, tutorials, videos, demos, gamedev or free software events, support on the Q&A, forums, Contributors Chat, Discord, etc. Participate! Being a user and advocate helps spread the word about our great engine, which has no marketing budget and can therefore only rely on its community to become more mainstream.

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

Toutes les pull requests doivent passer par un processus de révision avant d'être acceptées. En fonction de l'ampleur des modifications, il peut s'écouler un certain temps avant que le responsable de la partie modifiée du moteur ne fournisse son avis. Nous apprécions tous nos contributeurs et leur demandons d'être patients pendant ce temps, car il est normal que dans un projet open source comme Godot, il y ait beaucoup plus de contributions que de personnes qui les valident.

Pour s'assurer que votre temps et vos efforts ne sont pas gaspillés, il est recommandé de vérifier l'idée d'abord avant de la mettre en œuvre et de la soumettre à un examen en tant que PR. À cette fin, Godot a un système de proposition. Son utilisation est encouragée pour planifier des changements et en discuter avec la communauté. Les détails de mise en œuvre peuvent également être discutés avec d'autres contributeurs sur le Chat des contributeurs de Godot.

Note

Les propositions ne sont nécessaires que pour travailler sur une amélioration ou une nouvelle fonctionnalité. Les rapports de bogue sont suffisants pour résoudre les problèmes.

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 uses GitHub's issue tracker for bug reports and enhancement suggestions. You will need a GitHub account to be able to open a new issue there, and click on the New issue button.

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.

  • Godot version. This is a must-have. Some issues might be relevant in the current stable release, but fixed in the development branch, or the other way around. You might also be using an obsolete version of Godot and experiencing a known issue fixed in a later version, so knowing this from the start helps to speed up the diagnosis.

  • How to reproduce the bug. In the majority of cases, bugs are reproducible, i.e. it is possible to trigger them reliably by following some steps. Please always describe those steps as clearly as possible, so that everyone can try to reproduce the issue and confirm it. Ideally, make a demo project that reproduces this issue out of the box, zip it and attach it to the issue (you can do this by drag and drop). Even if you think that the issue is trivial to reproduce, adding a minimal project that lets everyone reproduce it is a big added value. You have to keep in mind that there are thousands of issues in the tracker, and developers can only dedicate little time to each issue.

When you click the New issue button, you should be presented with a text area prefilled with our issue template. Please try to follow it so that all issues are consistent and provide the required information.

Contribuer à la documentation

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

  • The class reference. This is the documentation for the complete Godot API as exposed to GDScript and the other scripting languages. It can be consulted offline, directly in Godot's code editor, or online at Godot API. To contribute to the class reference, you have to edit the XML file corresponding to the class and make a pull request. See Contribuer à la référence des classes and Class reference writing guidelines for more details.

  • The tutorials and engine documentation and its translations. This is the part you are reading now, which is distributed in the HTML format. Its contents are generated from plain text files in the reStructured Text (rst) format, to which you can contribute via pull requests on the godot-docs GitHub repository. See Contribuer à la documentation for more details.

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.