Outils du site

fr:godot:collaborer

Collaborer à la création du client de jeu 3D Godot

Le workflow de travail

Créez toujours une Issue avant de créer une branche qui n'y est pas référencée.
Cela permet de suivre le travail en vérifiant si une branche Git avec ce numéro existe, de façon à éviter de refaire du travail déjà commencé.

Avoir un dépôt sur lequel travailler

Mise en place d'un dépôt personnel (fork)

Pour commencer, il vous faudra forker le dépôt principal : khaganat/mmorpg_khanat/khanat-client. Ainsi, vous aurez votre propre dépôt, sur lequel vous pourrez effectuer vos modification sans interférer avec le dépôt principal.

Pour cela, il vous suffit de clique sur le bouton suivant sur la page d’accueil du projet.

Vous serrez alors redirigé vers votre copie du dépôt.

Travailler directement sur le dépôt principal

Si vous êtes un développeur « officiel » chez nous, vous aurez accès au dépôt principal sur notre GitLab : Client Godot 3D Khanat.

Vous n'aurez pas à créer un dépôt personnel (sauf si vous en avez envie) pour pouvoir contribuer, il vous suffira de travailler sur des branches en interne.

Le dépôt et ses branches

Khanat utilise un workflow simplifié. Les branches principales sont :

  • Branche Master : Branche stable, qui contient toutes les données sonores qui servent au jeu, ainsi que les fichiers source.
  • Branche module/XXX_nom_du_module : Branche contenant le développement d’un module (voir ci-dessous) XXX, en cours de travail.
  • Branche Develop : Branche historique, utilisées lors des tests préliminaires, obsolète.

Les branches feature, que ce soit sur votre fork ou sur les dépôts officiels, doivent être nommées de la façon suivante :

  • Branche Module : Doit être nommée “module/[numéro_du_module][nom du module sans espaces ni ponctuation]” en se basant sur les modules définis dans le cahier des charges
    • Exemple : “feature/3_dialogue”

Publication d'un module

Une fois que vous considérez le module que vous avez développé terminé, vous pouvez créer une Merge Request, à destination de Master. Cette requête doit respecter ces impératifs :

  • La Merge Request doit clairement expliquer comment elle répond à la feature

Gestion des Merge Request

Lorsqu'on a terminé un Module, il faut faire une demande de Merge Request en expliquant en quoi la tâche est terminée et l'affecter à une autre personne même si on a la capacité de merger directement.

Cela permettra d'avoir un contrôle, ne serait-ce que formel, sur l'ajout.

On ne merge jamais soi-même directement sur Master.

Gestion des Issues

Créez les demandes de fonctionnaltiés ou les erreurs sur le système Gitlab de ce dépôt plutôt que sur la base TAF (qui sert surtout aux aspects non-techniques du projet Khaganat). Vous pouvez les rédiger en français par simplicité, mais dans la mesure du possible on essaiera de les traduire pour permettre à des contributeurs non francophones de collaborer. L'idéal est d'utiliser l'anglais et le français dans vos tickets, cela maximise les chances que quelqu'un puisse y répondre.

Avant de commencer une tâche, créez une Issue que vous vous attribuez, comme ça on sait que quelqu'un a commencé à travailler sur ce sujet.

Les travaux à faire, modifications de fichier, créations, doivent être indiqués en se servant du système d'Issues de ce dépôt : Issue sur Godot 3D client Khanat

Il suffit de cliquer sur :

Vous renseignez ensuite les différents champs.

Le titre doit être concis et le plus explicite possible.
Par contre, n'hésitez pas à être le plus précis possible dans la zone Description.

Il y a ensuite 3 zones de champs à renseigner :

  • Assignee pour indiquer la personne à qui affecter la tâche ;
  • Milestone qui désigne la version du projet pour laquelle ce travail devra être fait (voir ci-dessous) ;
  • Labels permet de choisir des tags pour déterminer le genre de tâche (voir ci-dessous) ;
  • Select due date propose de fixer une date de remise des travaux.

Dans le doute, n'indiquez rien dans ces quatre champs. De toute façon, tout est éditable a posteriori donc ce n'est pas grave si vous faites des erreurs ou n'êtes pas assez précis.

Gestion des dossiers et des fichiers

Les commentaires dans le code/les scripts se font en anglais, de façon à ce que le code soit international.

Si vous ajoutez des fichiers d’assets (sons, images, modèle 3D…), il faut impérativement y adjoindre un fichier .json de même nom, qui comportera le suivi des contributions, de façon à permettre de tracer la paternité des contributions. SI il existe déjà et que vous faites une modification au fichier d’asset, ajoutez juste votre nom.

La structure du fichier est la suivante :

myasset.svg.json
{
        "contributors":
                [{
                        "name" : "John Smith",
                        "email" : "john@johnsmith.com",
                        "url" : "http://johnsmith.com"
                },
                {
                        "name" : "Jane Smith",
                        "email" : "jane@janesmith.com",
                        "url" : "http://janesmith.com"
                }],
        "license" : "CC-BY-SA-4.0"
}

Description :

  • contributors :
    • indiquer le nom (obligatoire), le courriel (facultatif) et une url de référence (facultatif) pour chaque contributeur à ce fichier
  • licence :
    • indiquer la licence appliquée aux fichiers de ce répertoire, pour uniformiser les références, utiliser les codes spdx, ce sera par défaut “CC-BY-SA-4.0” (ou AGPL-3.0-or-later si ce sont des scripts/codes), mais cela peut être une licence plus permissive compatible.

N'oubliez pas de nommer le json du même nom que votre asset, extension comprise ! Cela veut dire que si vous faites un pendo.png, le fichier json associé sera pendo.png.json.

Le nommage des assets devra obéir à une certaine nomenclature sur les dépôts officiels, afin d'éviter les doublons dans les noms. Cette nomenclature reste à définir.

Gestion des Commits

On rédige ses commits en anglais, de façon à ce que le code soit international (même si c’est du franglais, aucune importance).

Un commit est impérativement nommé en référence à un Bug qu’il participe à corriger ou une Feature qu’il contribue à implémenter.

Gestion des Milestones

On se servira des milestones définies par le cahier des charges du client : versions.

Gestion des Tags

Nous n'utilisons pas de Tags sur ce dépôt Git pour le moment.

Étudier la question et voir comment les déployer sur le projet

Gestion des Labels

Nous n’utilisons pour l’instant que deux Labels, qui sont affectés aux Issues :

  • Bug : Pour les Issues décrivant un comportement anormal, une erreur ;
  • Feature : Pour les Issues décrivant une fonctionnalité nouvelle à apporter.
fr/godot/collaborer.txt · Dernière modification: 2020/06/19 08:37 par YannK