Forum Opensourcing [A lire] Explications open source

 [A lire] Explications open source

Oxymore

Fonctionnement

Le code d'Asylamba est désormais open source. Cela signifie que les personnes intéressées à améliorer le jeu peuvent contribuer. Toutefois, tout ne sera pas accepté sur le dépôt officiel, il faut d'abord se coordonner : proposer une idée, la faire accepter par la communauté ainsi que par l'équipe de dev, trouver des personnes capables de faire les modifications, etc.

Voici donc un guide qui explique comment tout cela fonctionne.

Pour rappel, le projet officiel se trouve sur Github à l'adresse : https://github.com/rtfmcorp/asylamba-game

Différentes sortes de modifications

Comme expliqué dans le stream Twitch du 2 novembre 2016, nous distinguons trois types de modifications. Chacune d'elle concerne des améliorations bien spécifiques et ont également un processus différent pour son acceptation. Voici donc toutes les infos qu'il faut :

Type A : Modification technique

Toutes les modifications techiques font partie de cette catégorie. Elles seront acceptées sans trop de débat si elles sont techniquement justifiables. Voici quelques exemples qui entrent dans cette catégorie :

  • amélioration du code : refactoring, adaptation aux conventions du langage (PSR : PHP Standards Recommendations), adaptations MVC, amélioration des performances du code
  • internationalisation : externalisation de toutes les chaînes de caractères dans des fichiers de langue pour une possible traduction du jeu
  • REST : créations d'une API REST dans le but de dissocier l'interface du coeur (et potentiellement faciliter la création d'une app mobile)
  • simplification du déploiement : Docker, fichiers de configurations, testing, etc.

Type B : Correction

Cette catégorie concerne principalement les corrections de bugs et les améliorations diverses qui ne changent pas le gameplay du jeu. Voici les changements qui concernent cette catégorie :

  • corrections de bugs
  • améliorations de l'ergonomie
  • améliorations du calibrage
  • légères modifications de fonctionnalité

Type C : Ajout de fonctionnalité

Et la dernière catégorie concerne les changements qui touchent au fonctionnement du jeu en lui-même. Ces changements devront être discuté puis validés pour avoir une chance d'être acceptés sur le dépôt officiel.

  • suppressions de fonctionnalités
  • ajouts de fonctionnalités
  • modifications de fonctionnalités

Comment s'y prendre pour chaque type

Type A : Modification technique

Les modifications de type A concernent principalement les développeurs car ce sont des modifications purement techniques. Ici tout se passe directement sur Github. Les modifications souhaitées doivent être ajoutées dans les issues. Une fois cette étape faite, une personne en charge (Estiocle, abdelaz3r ou Oxymore) va donner son aval ou non (discussion en privé pour les détails). Les modifications peuvent alors être faites et proposées en Pull Request.

Type B : Correction

Pour les corrections, tout le monde peut contribuer ! La première étape est de créer une issue en expliquant le problème (avec captures d'écran si besoin). Tous les bugs peuvent/doivent être reportés là-bas pour avoir une chance d'être résolus.

Par la suite, un développeur peut choisir un des bugs et décider de le régler. Une Pull Request et le tour est joué.

Type C : Ajout de fonctionnalité

Pour les deux premiers types, tout se passe sur Github. Pour cette dernière catégorie par contre, il est indispensable de passer par le forum ici présent !

Si quelqu'un a une idée de modif/ajout/suppression d'une fonctionnalité (ou tout autre changement qui touche aux mécaniques de base), il va devoir créer un sujet sur ce forum en expliquant son idée dans le détail. Tout le monde peut ensuite donner son avis sur le sujet. L'idée est de déclencher un débat si oui ou non la modification est cohérente et va dans le sens du jeu.

Lorsque la discussion arrive à son terme, un vote sera fait. Si le vote passe, il faudra avoir également l'avis des core devs.

Une fois la modification acceptée, il faut trouver des gens qui sont ok pour faire la modification. Cela impliquera des développeurs avec les compétences pour le faire, ça va changer de cas en cas. Il n'y a aucun sens à faire une modification qui implique un changement de design si aucun développeur front-end est dans l'équipe par exemple.

Nous insistons ici pour que les discussions/débats soient faits sur le forum et non sur Discord. Cela pour plusieurs raison : 1) Tout le monde n'est pas sur Discord. 2) Ce qui se discute sur Discord va se perdre dans le flux car c'est un chat, alors que le forum restera là. Il est par contre encouragé de discuter d'une idée sur Discord avant de la mettre sur le forum, ainsi elle sera déjà mieux réfléchie.

Merci donc de respecter ces quelques lignes directrices pour que tout soit fait dans les règles de l'art.

Oxymore admin, 8 nov. 2016, 23h11

abdelaz3r

Dans un soucis de lisibilité, les features qui sont explicitement acceptées par l'un ou l'autre des 3 dev (oxy, estiocle et moi-même) seront marquée comme sujet résolu. Cela ne veut bien sur pas dire que de nouvelles discussions ne sont pas possible sur le sujet, ça veut juste dire qu'un des membres de l'équipe a approuvé la feature. Je recommande donc de ne pas marquer en résolu les autres sujets !

abdelaz3r admin, 4 juil. 2017, 16h21

Répondre

Se connecterou Créer un compte

Vous devez être connecté pour poster un message