Le dépôt de travail est situé sur notre forge logicielle : Khanat

La licence choisir pour le code est la licence GNU Affero General Public License (version française)

Créez les demandes de fonctionnalités ou les erreurs sur le système de ticket et pas sur la base TAF (qui sert surtout aux aspects non-techniques du projet Khaganat). Il n’y a pas d’impératif d’utiliser l’anglais comme dans les commits et les commentaires du code, mais il est possible de l’utiliser, selon les personnes avec qui vous pensez collaborer. L'idéal serait d'utiliser l'anglais et le français dans vos tickets, mais vu la surcharge de travail que cela entraîne, ce n’est pas du tout obligatoire.

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

Il y a ensuite quelques zones de champs à renseigner :

• No Branch/Tag specified : si vous savez quelle est la branche affectée par votre problème ou celle qui doit recevoir la fonctionnalité décrite
• Labels : Si c’est un bug, une nouvelle fonctionnalité… La liste des catégories possibles pour les tickets a une page dédiée sur la forge.
• Milestone : Pas utilisé pour le moment
• Projects : Pour déterminer le project auquel appartient ce ticket
• Assignees : Pour assigner cette tâche à une contributrice

Dans le doute, n'indiquez rien dans ces 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.

Il est ensuite possible d’échanger avec d’autres contributrices autour du sujet, comme dans un forum.

Pour commencer, il vous faudra forker le dépôt principal : Khanat. 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 cliquer sur le bouton `Fork` sur la page d’accueil du projet :

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

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

• Branche main : c’est la branche qui contient le code qui est compilé pour fournir le client de jeu en cours.

• Branche vXX_XX : Branche contenant le développement de la version mineure indiquée. La première version étant la 0.1, la première branche de travail est donc la `v00_01`.

Vous devez créer une Pull Request, à destination de la branche de travail correspondante sur notre dépôt. Cette requête doit respecter ces impératifs :

• elle doit avoir comme début de titre « WIP: »le temps qu’elle puisse être testée et discutée
• son titre doit être de la forme « WIP: categorie: Description succincte (en anglais, même approximatif) » (les catégories servent à organiser le changelog).
• si elle correspond à la résolution d’un ticket, elle doit comporter en dernière ligne de description une commande pour fermer le ticket correspondant, du type « Closes #2 ».
• 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).

Dans la mesure du possible, on a au moins deux personnes qui valident la Pull Request avant acceptation et, même si on a les autorisations sur le dépôt, jamais on ne merge jamais soi-même directement son code.

Il ne faut pas hésiter à laisser des commentaires sur la demande de Pull Request, cette page est là pour expliquer les soucis, détailler l’approche etc. Cela permet de s’assurer que les solutions retenues sont pertinentes pour les autres contributrices et de faciliter l’intégration finale. On peut y citer les éventuels tickets en rapport avec la proposition.

Les catégories actuellement utilisées sont :

• Added : lorsque de nouvelles fonctionnalités ont été corrigées.
• Changed : lorsque des fonctionnalités ont été refactorisées, augmentées ou modifiées
• Fixed : pour la correction de bugs
• CI : pour ce qui concerne les automatismes
• Docs : lorsque cela ne concerne que de la documentation du code ou la génération de documents annexes. Aucune fonctionnalité ne doit avoir été altérée.

Une fois que l’ensemble des Tickets/Issues d’un projet a été résolu et que le client a atteint le point où il semble suffisamment achevé et stable, on peut le passer sur la branche « main ».

Il est indispensable de bien vérifier le changelog à ce moment là, selon le modèle de keepachangelog.com. Un changelog permet d'avoir une idée claire de ce qui est possible/implémenté à chaque itération.

Nous n'obtiendrons pas un client complet au premier jet. Nous proposons donc un succession de versions, chacune ajoutant de nouvelles fonctionnalités itérativement à la précédente.

Chaque version est numérotée x.y.z (voir la gestion sémantique de version).

• x = version majeure. On le change quand les changements ne sont pas rétrocompatibles
• y = version mineure. L’incrémentation se fait lorsqu’un ensemble de nouvelles fonctionnalités défini a été intégré, la compatibilité doit être maintenue, sauf dans le cas où la version majeure est en 0, car de nombreux changements peuvent être nécessaires avant de passer à la version 1.0.
• z = version corrective. Incrémentée lorsque des correctifs de bugs sont ajoutés à une version mineure, sans ajout de nouvelle fonctionnalité.

Le but de la 0.1 est d’avoir un client qui permette de déplacer le personnage dans un environnement minimaliste statique, avec un résultat visuel sobre mais attrayant, présentant des spécificités du monde du Khanat et simple techniquement afin de tester les outils et processus de collaboration. Un chat doit permettre de dialoguer entre joueuses.

Ce sera l’occasion de mettre en place un second dépôt pour les sources graphiques qui serviront à créer les assets glTF et de créer une automatisation à pour compiler les clients à fournir aux joueuses. Enfin, un troisième dépôt sera utilisé pour les sources sonores.

Lien vers le suivi du projet sur la forge : Khanat - version 0.1