Journal Cinq ans de projets libres: bilan et retour d'expérience sur la contribution

55
2
nov.
2015

Sommaire

Voilà 5 ans que je produis du logiciel libre. J'ai pris l'habitude de publier chaque année mon retour d'expérience sur ce sujet. J'ai parlé de mes premiers pas, de mes doutes, de ce que j'ai appris sur le code, des présentations publiques, de la communauté et enfin de l'impact du logiciel libre sur l'entreprise. C'est déjà un bon tour de la question. Alors qu'est ce qui ferait un bon sujet pour cette année ? Et bien je vais simplement vous parler de la contribution. C'est l'essence du projet libre, je ne pouvais passer à côté. A travers cet article, je vais donc vous raconter ce que j'ai ressenti en étant des deux côtés de la barrière. Mais, avant de rentrer plus dans les détails, je vous donne le contexte avec un résumé de mes aventures de l'année passée !

Ce que j'ai fait

J'ai encore beaucoup codé et principalement en Coffeescript pour le navigateur et le serveur (Node.js). Je voulais développer mieux et essayer d'autres langages mais je n'y suis pas arrivé. J'ai beaucoup travaillé dans l'urgence et n'ai pas testé de nouveaux outils.

J'ai surtout focalisé mes efforts sur Cozy. En effet, le projet a pris de l'ampleur. La communauté s'est beaucoup développée. J'ai aussi plus de collègues. Autre fait notable, maintenant je travaille non seulement avec des gens très compétents mais aussi avec des personnalités du milieu ! Parmi eux nous trouvons Tristan Nitot, qui a notamment fondé Mozilla Europe, et Bruno Michel, qui parmi d'autre choses a refait et maintient LinuxFR. J'ai donc évolué dans un environnement très stimulant et instructif.

Mais surtout cette année, chez Cozy, nous avons eu à gérer beaucoup de contributions tant internes (des collègues) que externes. D'un côté l'équipe Cozy s'est affirmée et a grandi. De l'autre, de nombreuses personnes sont venus contribuer. L'impact n'est donc pas négligeable… Car faire les bonnes choses pour que les gens travaillent bien en équipe est difficile. Mais bien intégrer des contributions diverses et aléatoires l'est encore plus (heureusement que je n'étais pas seul pour y faire face !). Malgré ça j'ai quand même pu contribuer à droite et à gauche. Dans la suite, je vais donc vous faire part de comment j'ai vécu expérience en tant que contributeur et intégrateur de contributions.

Contribuer

Faire un rapport de bug

C'est l'action de transmettre la description d'un bug que l'on a rencontré aux auteurs du logiciel. C'est un acte qui parait anodin mais qui requiert d'être bien fait pour être productif. En effet, si le message rédigé n'est pas compréhensible, il n'est pas traitable. Rédiger un rapport de bug demande de la rigueur sur la rédaction. Cela demande aussi de bien décrire le contexte dans lequel le bug se produit.
J'en ai peu rédigé mais j'étais, à chaque fois, content de le faire. Par contre, j'ai parfois été un peu déçu par les réponses reçues. En effet, les réactions des développeurs sont diverses: dans certains cas, les demandes sont ignorées ou fermées un peu brutalement (les développeurs ont vite fait de mettre ça sur le dos d'une dépendance). Heureusement elles peuvent être bien reçues et traitées. On est alors remercié, ce qui est plutôt sympa.

Exemple : Voici un rapport de bug que j'ai rédigé. L'interaction est intéressante. On me demande de rédiger un test en échec lié à mon bug. Un autre contributeur vient corriger le bug ensuite.

Corriger une documentation

C'est l'action d'ajouter un élément manquant ou de corriger une faute d'orthographe dans une documentation. Encore une fois, cela demande de bien rédiger mais au final cela ne prend pas trop de temps. Ce genre de corrections sont toujours bien appréciées et acceptées. C'est vraiment un bon moyen de commencer à contribuer à un projet.

Exemple : Là je corrige une documentation. Cela intervient après une discussion pour en savoir plus sur l'état du projet. Le mainteneur intègre vite la modification et me remercie.

Faire une correction de bug

Corriger un bug ne requiert pas de comprendre toute l'architecture de l'application. Ce qui est consommateur de temps c'est de s'assurer que les tests automatiques du projet fonctionnent toujours et d'en ajouter s'il en manque. Enfin, il faut bien commenter sa modification. Généralement cela se passe bien.
Attention, assurez vous aussi que personne ne travaille déjà sur ce bug avant. Pour cela vous pouvez en discuter sur le ticket concerné.

Exemple: Je n'ai pas retrouvé d'exemple pour à ce sujet.

Ajouter une fonctionnalité

Je ne me suis lancé là-dedans qu'une fois et, malheureusement, l'expérience fut assez mauvaise. Ayant beaucoup utilisé le framework Express JS pour Node.js, je me suis dit qu'il serait intéressant d'y contribuer. J'ai donc choisi une demande d'amélioration simple de leur côté. Cela m'a demandé beaucoup de boulot. J'ai d'abord dû bien comprendre la demande et me documenter sur la fonctionnalité demandée (permettre au framework d'alimenter un traceur à des fins de debug).
J'ai posé de nombreuses questions pour être sûr que je n'étais pas à côté de la plaque. Ensuite j'ai du comprendre une partie du code du framekwork. Enfin j'ai pu développer la fonctionnalité demandée. Au début j'ai eu du feedback intéressant du mainteneur principal sur ce que j'avais réalisé. Mais ensuite d'autres contributeurs sont venus donner leur avis. Pertinents mais un peu perfectionniste à mon goût. J'ai quand même joué le jeu et ait subi plusieurs allers et retours, Finalement mon code n'a jamais été fusionné.
Conclusion ajouter une fonctionnalité importante n'est pas toujours bien reçu. Il ne faut pas s'attendre forcément à un retour positif.

Exemple : Pour le projet Express, mon ajout aboutira à une discussion de 49 commentaires sans fusion au final. A l'inverse voici une modification bien reçue par l'auteur de Kresus, une app de gestion banquaire. Cette fois l'auteur est très content !

Faire un talk sur une techno pas à soi.

J'ai fait deux talks présentants la base de données dans le browser PouchDB. Les auteurs étaient très contents. Je me suis senti utile: c'était motivant pour eux et ça faisait découvrir une belle techno à plein de gens.

Exemple : Voilà la vidéo de ma présentation aux Human talks sur PouchDB. Les auteurs ont aussi manifesté leur joie sur les réseaux sociaux suite à ma présentation à cette présentation faite à DotJS.

Faire un don

Des fois le moyen le plus simple d'aider est de faire un don. Cela peut permettre à un groupe ou organisation d'améliorer ses conditions de travail ou les services qu'il propose. Ainsi j'ai aidé l'APRIL et le projet Salut à Toi. J'ai encore vu des gens contents !

Bénévolat

J'ai fait un peu de bénévolat au FOSDEM. Cela consistait à réaliser des actions simples comme m'occuper du vestiaire. C'est une contrib qui a permis de rendre l'événement un peu mieux. En plus, c'est à la portée de tout le monde. Pareil que pour le talk, le niveau de satisfaction était élevé ! C'est le genre de contribs auxquelles on ne pense pas toujours mais bien utile. Les gens de l'événement m'ont chaleureusement remercié et j'ai gagné du karma et un tee-shirt FOSDEM Volunteer.

Image Tee-shirt FOSDEM Volunteer.

C'est fini pour la partie contributeur. Passons maintenant à la partie recevoir une contribution. Mais avant ça, je voulais décerner une mention spéciale au projet PouchDB. L'accueil des auteurs et leur rigueur m'ont bien motivé !

Recevoir une contribution

Recevoir une traduction

La traduction est une belle contribution car elle permet à des gens non techniques de participer. C'est très stimulant d'en recevoir une. Bien la gérer par contre n'est pas évident. Car lorsque les messages de l'application bougent les traductions sont perdues. De plus les gens non techniques ne sont pas familiers des outils de gestion de version. Il faut donc souvent se tourner vers des outils en ligne dédiés au travail traduction collaboratif.

Ce que je fais : je remercie la personne et la renvoie vers Transifex, la plateforme que nous utilisons chez Cozy. Avoir un outil dédié est beaucoup plus pratique de demander aux gens d'utiliser Git et Github.

Recevoir un rapport de bug

Une autre une contrib à la portée de tous… Enfin de ceux familiers avec les outils de gestion de tickets ! C'est très satisfaisant d'en recevoir une car elle vous démontre que d'autres personnes se servent ou veulent se servir de votre application. Toutefois le rapport de bug se doit d'être bien rédigé pour ne pas faire perdre trop de temps en aller et retours. Recevoir beaucoup de rapports de bugs peut s'avérer oppressant.

Ce que je fais : je remercie la personne. Ensuite, je demande des détails si nécessaire. Lorsque le travail est terminé et livré, je vérifie avec la personne que le bug est bien résolu. Si c'est ok ou si je n'ai pas de nouvelles dans les semaines qui suivent je ferme le bug.

Exemple: Un rapport de bug simple et bien traitée (remerciements et confirmation inclus).

Recevoir une demande d'amélioration, un feedback

Idem que précédemment, c'est très satisfaisant et requiert au contributeur de maitrîser un outil de gestion de tickets. Toutefois ces demandes sont généralement difficiles à prendre en compte. La liste des bugs et des idées est souvent déjà suffisante. Là où ça devient très parlant, c'est quand la demande se répète, on comprend donc qu'il faut faire quelque chose.

Ce que je fais : je remercie la personne et laisse le ticket ouvert jusqu'à implémentation de la fonctionnalité.
Plus récemment j'ai demandé aux contributeurs de plussoyer une demande si elle leur plait. C'est un bon moyen d'évaluer la popularité de celle-ci.

Exemple : Voilà une simple demande d'amélioration que j'ai traitée pour la lib request-json. Par contre des fois la demande est automatiquement fermée par Github suite à l'intégration du correctif, ce qui n'est pas très sympa pour le contributeur.

Recevoir une correction de bug

C'est une très bonne contribution à recevoir. Par contre, si le correctif n'est pas parfait, c'est délicat de demander d'améliorer des modifications (ajout de commentaires ou de tests par exemple). Heureusement, les contributeurs sont assez contents de bien faire le travail, donc on peut être exigeant. Une fois intégré, c'est une petite victoire. Le bug a été corrigé sans votre intervention et la communauté du logiciel se renforce !

Ce que je fais : Suite aux remerciements, je fais une revue du correctif et fusionne les changements si tout est ok. Je rajoute le nom du contributeur à la liste des contributeurs (enfin quand j'y pense !).

Exemple : Ici je remercie le contributeur et intègre ses changements. Il apparait ensuite dans liste des contributeurs.
Certains associent systématiquement une modification à un ticket. Même si je ne le fais pas, il faut bien admettre que c'est une bonne pratique.

Recevoir une correction de documentation

Très agréable aussi, ces corrections se valident très rapidement et rendent le projet plus crédible.

Ce que je fais : Je vérifie, je remercie, j'intégre des modifications et rajoute à la liste des contributeurs.

Exemple : Ici j'intègre des corrections d'anglais sur la doc de Cozy. Je montre ma joie et j'intègre.

Recevoir une fonctionnalité

Cette contribution est plus délicate. En effet d'un côté c'est très plaisant de la recevoir. De l'autre l'implémentation n'est pas toujours satisfaisante. En effet, pour le contributeur c'est difficile de coder dans le style du ou des mainteneurs principaux et de bien faire l'implémentation. Par contre si c'est bien fait, ce n'est que du bonheur !

Ce que je fais : Ma réaction est très variable. Ca n'arrive pas si souvent et c'est vraiment du cas par cas. Si j'ai une recommandation, c'est de bien expliquer dans un ticket avant de coder ce que vous comptez faire.
Pour les contributions mal fichues, je demande au contributeur de corriger. Pour les détails je les prends à ma charge pour ne pas le décourager. Intégrer ce genre de modifications prend du temps dans tous les cas.

Exemple : Voici un ajout de fonctionnalité qui a demandé du boulot aux deux parties. Le code ne nous convenait pas tant dans l'architecture que dans le style. Nous avons fait la revue de code pour apprendre le style attendu. Ensuite nous avons aidé le contributeur à revoir son architecture pour qu'elle nous satisfasse.

Recevoir beaucoup de code

Ca n'arrive pas souvent mais quand c'est le cas, il n'y a pas à dire, on est très content ! Malheureusement, parfois ça devient difficile. Car intégrer toutes les modifications imposent un certain rythme qu'il n'est pas facile à tenir.

Ce que je fais : ce n'est arrivé qu'une fois et j'ai fini par refuser les modifications qui m'étaient envoyées. Au début je faisais de mon mieux pour tout intégrer et faire en sorte que ça respecte la philosophie du projet. Mais je n'ai pas pu tenir le rythme. J'ai fini par fermer une demande de modifications. Le code n'était pas commenté, les commits étaient peu clairs et je n'avais plus le temps de remettre le tout au propre. Le contributeur s'est vexé et a arrêté de faire des modifs.

Exemple : Ce cas m'est arrivé pour le projet expérimental Cozy Light. Après de nombreux échanges, j'ai refusé cette modification. Je dois avouer que je ne savais pas du tout comment gérer la situation. Et l'effet s'est bien ressenti. Après ça le contributeur s'est vexé et a arrêté de contribuer.

Voir une app se développer sur la plateforme

Celle ci est le genre de contrib qui n'existe pas pour tous les projets. Au mieux, les projets proposent au contributeur de faire des plugins. Mais le projet Cozy permet de réaliser des applications complètes. Pour les plateformes, c'est un peu la contribution ultime. En effet on voit un autre projet se développer au dessus d'un autre. Ensuite, le nouveau projet se constitue à son tour sa propre communauté!

Exemple : L'application Kresus est partie d'un fork d'une app existante. Un an après, voici le sujet Kresus sur le forum de Cozy. L'auteur y annonce ses nouveautés. Le sujet engendre une discussion de près de de 200 messages. Tout le monde est content !

Voir un contributeur en aider un autre

Là on voit la communauté du projet qu'on a initié devenir autonome. C'est un peu l'extase pour le mainteneur !

Exemple : un contributeur se pose une questions sur le processus d'installation. Un autre vient lui fournir une explication.

Recevoir des encouragements

Ca arrive par mail, via le forum ou via IRC. Encore une fois c'est génial de recevoir ce type de messages. Ca coûte pas grand chose, donc ne vous retenez pas si vous aimez bien un projet ! J'en ai encore reçu un hier. C'est très encourageant.

Rejoindre une communauté

Conclusion

Et voilà, le bilan se termine ici. La contribution est le moment le plus exaltant du projet libre. Les esprits se connectent pour réaliser un travail collaboratif. La magie se crée. Quand j'ai commencé à écrire du code libre, ce qui m'attirait le plus était de faire les choses enfin proprement et à ma manière. Aujourd'hui, ce qui me motive le plus c'est de voir le projet vivre sa vie et d'observer les interactions des contributeurs.

L'acte de contribuer permet de faire avancer significativement les projets que vous aimez. Les mainteneurs gagnent du temps, sont aiguillés dans la bonne direction et sont plus motivés. C'est aussi l'occasion pour vous de progresser techniquement et sur le plan rédactionnel. Bref c'est une bonne source de points de karma à portée de main. N'hésitez pas à en abuser !

Ce bilan est aussi l'occasion de clore un premier cycle exploratoire du monde du logiciel libre. J'ai couvert les thèmes principaux que sont la mise en place d'un projet, son évangélisation, le rapport à la communauté, comment il s'intègre dans une entreprise et enfin comment se vit une contribution.
Pour les cinq prochaines années, rien est décidé mais j'ai déjà quelques idées. En dehors de continuer à travailler sur Cozy et Newebe, je vais essayer de découvrir d'autres langages (Go et Lua probablement). Et ce en contribuant plutôt qu'en montant un nouveau projet. Une autre chose que j'aimerais bien faire est de tester un développement écrit en Espéranto plutôt qu'en anglais (au moins dans les commentaires). Je n'en dis pas plus pour le moment, car je réserve cette histoire pour un prochain épisode !

  • # Différences entre les outils et les applications finales

    Posté par . Évalué à 10.

    Merci pour le petit résumé, il est intéressant de lire quelqu'un qui est des 2 côtés de la "barrière".

    Ceci étant dit, j'ai, comme j'imagine une frange non négligeable de la population qui visite linuxfr, déjà contribué à certains projets, ou au moins essayé.

    Du peu de contributions que j'ai tentées, j'ai discerné, peut-être à tord, plusieurs axes qui vont influencer le comportement en réponse de la contribution:

    • si le projet est un outil, ou un "produit" final.
    • le nombre de personnes occupées (temps plein ou partiel, professionnellement ou par loisir, je parle ici des contributeurs qui ont intégré, d'une façon ou d'une autre le cœur du projet) par la maintenance du projet, ou la taille de la communauté.
    • l'âge du projet.
    • la vitalité du projet.

    Je n'ai qu'une ou deux anecdotes sur des projets de type outils, uniquement des bibliothèques C ou C++ (la réaction des développeur change-t-elle en fonction du langage? Je n'en sais rien.). En général, j'ai eu l'impression, si le développement était encore actif, d'une certaine bienveillance.
    J'ai corrigé 2-3 bugs (one-liners, souvent) et erreurs ou imprécisions de doc ici et là.
    Dans le cas (oui, LE) ou j'ai corrigé une imprécision de la doc, j'en ai profité pour soumettre une demande de fonctionnalité (sur GLFW3, une histoire de presse-papier, j'avais surtout testé pour le fun, mais la doc était imprécise et le comportement faisait que si l'utilisateur (un dev, donc) considérait une erreur comme une raison de crash (comme moi, encore, même si parfois le contexte fait qu'il faut tenter de récupérer un état stable). Du coup, j'ai suggéré plusieurs choses: donner un moyen de vérifier que le presse-papier contiens effectivement des données avant de les récupérer, ou… je ne me souviens plus.
    Les devs ont opté (ce que j'aurai aussi fait, et donc ai mis en valeur dans ma suggestion) pour améliorer la précision de la doc et introduire une fonction pour vérifier que le presse papier contiens quelque chose dans une version future. On verra dans le futur si la fonctionnalité est implémentée… Ça ne me tenais pas vraiment à cœur, sinon j'aurai sûrement soumis un patch, je voulais juste jouer un peu avec le code quand je suis tombé sur le comportement surprenant en question.

    Sur des "produits finaux", en revanche, j'ai un peu plus à dire. j'ai tenté bien plus souvent d'aider, et les retours sont assez divers.
    Parfois, on à l'impression d'être ignoré, purement et simplement.
    J'ai en mémoire un vent sur Debian, ou j'ai signalé un bug de udev qui partait en boucle infinie, qui menait à une augmentation des processus udev, et donc une saturation de la RAM, ce qui mène à un état ou Linux ne répond juste plus. Au temps pour le fameux "dans l'open source on corrige en 2s les bugs signalés". Au final, il n'était pas tombé dans l'oubli, j'ai eu un retour sur mon mail plus d'un an après avoir soumis le bug.
    J'avoue, mon comportement n'a pas été modèle sur ce coup: au bout d'un an, j'ai encore une image disque avec les données qui reproduisent le bug, mais je n'ai même pas daigné répondre. J'ai mal pris le fait de ne même pas avoir le moindre retour en 12 mois. J'ose espérer que c'est humain. D'autant que, pendant ces 12 mois, Jessie est parue ( est-ce la raison pour laquelle je n'ai pas eu de retours avant? ) et les changements de Debian autant que mon évolution personnelle font qu'il ne me manque pas grand chose pour changer de distrib. Cette histoire à aussi dû contribuer à cette volonté, malgré que j'éprouve réellement un grand respect pour Debian.

    Dans d'autres cas le mainteneur est en désaccord avec le ticket, mais répond rapidement et poliment. Là, c'est agréable. Ça m'est arrivé, encore une fois sur Debian, par rapport à un jeu (mars shooter, plutôt fun, je vous le conseille) qui à une dépendance dure sur … des polices de caractères. Son argument était valide par rapport au projet, au final, donc je n'ai pas insisté (mais c'est probablement une des raisons qui font que je cesserai d'utiliser Debian quand j'aurai le courage d'aller sur une distro plus pointue).

    Il y à aussi le cas ou l'on cherche à s'impliquer, et ou l'on s'aperçois sur une session IRC laissée en suspend qu'en fait les gens préfèrent vous ignorer plutôt que de répondre. Même pas ils diraient qu'on va trop loin, non non, il préfère laisser les contributeurs potentiels rédiger des messages propres et essayer de patcher le code, sans leur dire qu'en fait, ils en ont rien à carrer. Je ne citerai pas le projet en question, mais vous comprendrez que j'ai juste arrêté de donner des nouvelles, du jour au lendemain. Aujourd'hui, il est encore vivant, tant mieux, il à évolué, tant mieux encore, mais j'ai constaté pas mal de régressions dans les fonctionnalités, et ça me fait autant sourire que mal (parce que si je voulais m'y impliquer c'est que je l'aime).

    Il y à aussi les projets, genre valyria tear (un jrpg, des plus prometteurs à mon avis), ou il y a peu de gens, qui sont heureux de recevoir les contributions, et vont jusqu'a recontacter les gens (un nettoyage des allocations mémoire C dans un code C++, je soupçonnais un memory leak de là mais ça n'a rien résolu… le problème viendrai peut-être de la lib pour lua du coup… Tant pis, le code semble avoir quand même été intégré vu que j'ai refondu pour respecter mieux le style de code qui semblait être le final, il faudrait que j'aille remercier).

    Enfin, il y à toutes sortes de projets, et ce ne sont pas mes expériences négatives avec certains qui m'empêcheront de tenter de contribuer à de nouveaux projets, que ce soit par le code ou par les tickets. Je reste par contre un véritable contributeur de passage, les rares fois ou j'ai tenté de m'impliquer à fond dans un projet m'ont tellement refroidi que je n'ai plus l'intention de m'intégrer dans une équipe (sauf boulot, mais c'est différent). Tant qu'a faire, je préfère encore forker ou réécrire, si j'ai trop de trucs à changer. Et le signaler au projet original, qui est du coup libre d'intégrer ou non les patchs.
    Oui, ça augmente potentiellement la fragmentation, mais entre nous: je m'en fiche. Je mets toujours un lien vers le projet originel, je l'averti aussi toujours en face, et s'il intègre assez de modifs, je vire mon fork.
    Au final, moi, je suis plus serein parce que je n'ai pas à me prendre la tête à convaincre par des mots qui ne serons même pas lus (et personne pour répondre franchement: "TL;DR" ou "rien à foutre de ton idée") et j'ai un soft qui marche comme je le veux. Et le projet originel est libre d'intégrer mes idées si ça lui chante et si ça fonctionne. Gagnant-gagnant pour moi.

    • [^] # Re: Différences entre les outils et les applications finales

      Posté par (page perso) . Évalué à 4.

      Merci pour ces informations qui complètent bien mon post. Tu as raison, dans mon article je n'ai pas intégré le contexte. Selon la gouvernance, d'acteurs impliqués et de type de projet (lib, appli bureau, appli web, outil sytème, etc.), il ne faut pas s'attendre aux mêmes types de réaction. Ca me fait remarquer que le sujet de la contribution est vaste et mériterait plus d'un article pour être bien couvert.

  • # Rapport de bug

    Posté par . Évalué à 2.

    La section « Recevoir une fonctionnalité » n'est pas typographiée correctement.

    Sinon merci pour ces articles forts intéressants.

    • [^] # Re: Rapport de bug

      Posté par (page perso) . Évalué à 2.

      corrigé, merci

      If you choose open source because you don't have to pay, but depend on it anyway, you're part of the problem.evloper) February 17, 2014

    • [^] # Re: Rapport de bug

      Posté par (page perso) . Évalué à 2.

      Pour rester dans les corrections :

      Un an après, voici le sujet Kresus sur le forum de Cozy.

      Le lien mis sur "sujet Kresus" pointe sur une entrée github liée à cozy-files. Après une petite recherche, je pense que le bon lien est : https://forum.cozy.io/t/app-kresus/224

  • # super et merci

    Posté par (page perso) . Évalué à 2.

    comme toujours un très bon journal, et très honnête, bravo !

    Tu as fait une autre contribution pour nous: suite à une de tes confs aux JDLL y'a quelques années (2 ou 3 ans) tu es venu à notre stand et nous a conseillé sur quelques modifs pour notre interface web (Libervia), ce qui nous a été bien utile, merci encore :).

    L'esperanto dans le code c'est une idée qui m'a traversé l'esprit aussi plus d'une fois, mais c'est un sujet délicat, je serais très intéressé par ton expérience éventuelle.

    Pour Lua j'avais commencé avec un excellent commentaire de stackoverflow qui a été supprimé depuis, mais qu'on peut retrouver ici ou là ou sur archive.org. Ça m'a permis de rapidement pouvoir m'attaquer à des modules pour Prosody (on peut ensuite utiliser directement la doc officielle ou demander de l'aide sur le salon du projet).

    • [^] # Re: super et merci

      Posté par (page perso) . Évalué à 2.

      A oui j'avais oublié ça ! Pour l'esperanto je te pingerai le jour où je m'y attaque mais ce sera pas pour tout de suite. Idem pour Lua. Je connais un fanatique du langage qui m'a déjà aiguillé sur des bonnes ressources.
      Pour Go, pour commencer, je suis en train de lire tout le site : http://gobyexample.com/ .

      • [^] # Re: super et merci

        Posté par (page perso) . Évalué à 2.

        Ça m’intéresse aussi les expérimentations de code en espéranto :-)
        Fais directement un journal le jour où tu te lance, ce sera plus simple que de contacter tous les potentiels intéressés :-P

        Pour lua, j’ai entamé la création d’un jeu basé sur LÖVE récemment, je suis bien plus convaincu par le framework que par le langage pour l’instant (Et par la communauté et les libs dispo aussi qui sont cools et variées). Je préfère les langages plus contraignants, c’est trop laxiste pour moi lua.

  • # demande est automatiquement fermée par Github

    Posté par . Évalué à 2.

    Par contre des fois la demande est automatiquement fermée par Github

    C'est normal: nono a utilisé une fonctionnalité de github pour fermer automatiquement une issue: https://help.github.com/articles/closing-issues-via-commit-messages/

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.