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

Posté par  (site web personnel) . Édité par Yves Bourguignon, Benoît Sibaud, Nils Ratusznik, Nÿco, bubar🦥, palm123 et Jehan. Modéré par Nils Ratusznik. Licence CC By‑SA.
Étiquettes :
32
8
fév.
2016
Communauté

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.

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é. À 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, entre autres choses, a refait et maintient LinuxFr.org. 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) qu'externes. D'un côté l'équipe Cozy s'est affirmée et a grandi. De l'autre, de nombreuses personnes sont venues 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 l'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 est toujours bien apprécié et accepté. 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é.

Je n'ai malheureusement pas retrouvé d'exemple à 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 dû comprendre une partie du code du framework. 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 perfectionnistes à mon goût. J'ai quand même joué le jeu et ai 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. À l'inverse voici une modification bien reçue par l'auteur de Kresus, une application de gestion bancaire. Cette fois l'auteur est très content !

Faire une présentation sur une techno pas à soi.

J'ai fait deux présentations concernant la base de données dans le navigateur 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 contribution sur 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 contribution 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 contributions 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 à la traduction collaborative.

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

Recevoir un rapport de bug

Une autre contribution à 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é (remerciements et confirmation inclus).

Recevoir une demande d'amélioration, un feedback

De même que précédemment, c'est très satisfaisant et requiert au contributeur de maitriser 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 (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. Ça 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

Cela 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 impose un certain rythme qui 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 modifications.

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 contribution qui n'existe pas pour tous les projets. Au mieux, les projets proposent au contributeur de faire des greffons. 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 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 question sur le processus d'installation. Un autre vient lui fournir une explication.

Recevoir des encouragements

Cela arrive par courriel, via le forum ou via IRC. Encore une fois c'est génial de recevoir ce type de message. Ça 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 !

Aller plus loin

  • # Vitalité de Cosy

    Posté par  (site web personnel) . Évalué à -5.

    1 mois depuis le dernier commit, ça ne fait pas très actif comme projet. Me trompe-je ?

  • # À propos des nouvelles fonctionnalités

    Posté par  (site web personnel) . Évalué à 10.

    Le plus terrible dans l'apport de nouvelles fonctionnalités est pour moi de n'avoir aucun retour sur la contribution. Il y a plusieurs outils tiers dans lesquels je me retrouve à faire des modifications au boulot, soit parce que j'ai des soucis à la compilation, soit parce que j'ai besoin d'une fonctionnalité, et depuis quelques temps j'essaie de remonter les modifications pour jouer le jeu du libre et aussi pour éviter d'avoir à les réappliquer quand je mets l'outil à jour. Bilan des courses, cinq pull requests, zéro merge et un seul retour.

    Par exemple, ajouter la composition de skins à un outil d'animation. Aucun retour. Est-ce trop gros ? Est-ce inintéressant ? J'appuie ma demande en citant trois entrées de forums qui demandent cette fonctionnalité mais les devs laissent dormir la requête.

    Sur un autre projet, je modifie la gestion des polices pour avoir un comportement homogène sur iOS, Android, Linux et OSX. Premier retour en une semaine et une demande de correction en un mois. Je traîne un peu et presque trois mois plus tard j'envoie les corrections. Et là c'est le silence. Je me dis que la pull request est trop grosses et je tente d'autre demandes, plus petites et triviales mais rien n'y fait, c'est toujours le silence.

    C'est assez difficile de rester motivé quand les contributions tombent ainsi dans l'oubli.

    • [^] # Re: À propos des nouvelles fonctionnalités

      Posté par  (site web personnel) . Évalué à 4.

      Bon ça me rassure sur mon expérience avec Express, je ne suis pas le seul à vivre une déception. Je pense que la prochaine fois je serai clair sur mes attentes au moment de proposer des modifications. Après il faut être indulgent avec les auteurs, ça peut demander beaucoup de boulot d'intégrer un développement externe.

    • [^] # Re: À propos des nouvelles fonctionnalités

      Posté par  . Évalué à 3.

      Ça c'est un soucis de gestion de communauté.

      Sur la page github on voit 1158 forks !! Il y a 47 pulls requests… tu n'as pas l'air seul. As-tu regardé les autres pull requests ?

      Ça vaudrait peut-être le coup de s'associer pour créer un fork avec d'autres contributeurs de pull requests… et faire une sorte de version communautaire, comme une surcouche au projet initial. Si j'ai bien compris, c'est aussi ça le logiciel libre :-) Ça deviendrait alors sans doute moins frustrant, ensuite libre au projet amont d'intégrer les pull requests… (tant mieux ou tant pis).

    • [^] # Re: À propos des nouvelles fonctionnalités

      Posté par  (site web personnel) . Évalué à 8.

      Hello,

      effectivement, c'est un peu hard quand tu as codé pendant 8h et que ta pull-request reste en carafe pendant des mois, sans réaction ni commentaire.

      Je pense que c'est différent selon les projets…
      Pour citer mon expérience, sur le projet QGIS, il y a pas mal de PR en souffrance. Néanmoins, si tu relances les personnes qui ont un droit de commit sur le dépôt, bien souvent ça avance plus vite. On peut le faire soit via Github, soit par email ou bien en arrosant la mailing-list des développeurs. Le principal frein de l'inclusion des PR (pour QGIS) est sans doute le peu de personnes capables d'effectuer une revue de code d'intérêt et vérifier que la PR s'intègre bien dans le code en cours (l'application est vaste et complexe). Et donc, il ne faut pas trop abuser de leur temps (ils travaillent également sur des nouvelles fonctionnalités pour lesquelles ils sont payés) et il faut se montrer patient. Par ailleurs, le projet QGIS a un cycle de développement assez court (publication d'une version stable tous les 4 mois) qui impose un gel de fonctionnalités d'un mois. Pendant ce temps, une PR qui ajoute des fonctionnalités sera forcément en attente.

      Donc, en général, les inclusions de code externe, ça peut mettre du temps. C'est souvent assez vrai sur un projet communautaire qui n'est pas englobé par une structure (une institution ou une boîte privée qui est la principale source de contribution ou de financement et qui embauche des gens pour gérer les contributions externes). Quand on a affaire à des projets où la gouvernance repose davantage sur une communauté, il faudra pouvoir bien s'insérer dans cette communauté, comprendre ses rythmes, son réseau social, ses outils et ses conventions de code pour trouver le meilleur moyen de contribuer. Pour l'instant, mon expérience sur QGIS reste vraiment très bonne. Les "commiters" détectent les nouveaux développeurs, leur donnent des explications, prennent du temps pour faire une revue de code avec des modifs et des commentaires, ne demandent pas la lune pour une première contribution (mais insistent sur quelques points incontournables comme les tests unitaires) et prennent également du temps pour finaliser la PR si le contributeur n'y arrive pas où si le travail de correction est assez simple.

      Peut-être que pour ton problème de PR sans effet, il faudrait pouvoir contacter (par un moyen ou un autre) les personnes en charge des commits pour appuyer tes demandes. Après, s'ils restent sourds à tes appels, changer de projet est parfois une solution (genre, viens contribuer au client Web de QGIS, on en a besoin) !

    • [^] # Re: À propos des nouvelles fonctionnalités

      Posté par  (site web personnel, Mastodon) . Évalué à 9.

      Il existe beaucoup de projets morts-nés, ou abandonnés, c'est un fait et je pense que ça a toujours été le cas (les plateformes de dépôts de code les ont juste rendus un peu plus visibles).
      Ensuite il y a des projets actifs, mais qui ne sont libres que par mode, sans comprendre ce que ça implique en général (même lorsque c'est à l'avantage du projet comme la contribution externe).

      Enfin — et c'est ce qui nous intéresse — il y a tous ces projets qui manquent de temps/main d'œuvre pour tout gérer. C'est vrai pour des petits projets (car c'est souvent une personne seule qui fait tout, souvent sur son temps libre), mais même aussi pour de gros projets. Peut-être parfois même encore plus le cas, car un gros projet est "victime" de son succès, mais sans avoir forcément énormément plus de développeurs (disons que le nombre de développeurs "core" augmente moins rapidement que les contributions "occasionnelles" et rapports de bugs). Personne n'est épargné sur ce point, je pense.
      En temps que développeur actif — voire parfois mainteneur — sur certains projets parfois extrêmement connus (GIMP), parfois moins (uchardet, crossroad…), j'adore autant contribuer du nouveau code qu'intégrer ou coordonner de nouvelles contributions. Je trouve cela extrêmement gratifiant d'intégrer du code externe sur un projet auquel on tient. Et c'est encore plus gratifiant quand on arrive à intégrer suffisamment un contributeur actif pour en faire un nouveau développeur core. Mais cela prend un temps fou. Parfois cela prend même plus de temps que si on avait essayé de coder la chose nous même. Très souvent, il faut revoir le code, le commenter, demander des changements, et nous même attendre les changements… Des mois passent. C'est normal.
      Recevoir des contributions externes est donc souvent plus qu'une question de gain de temps (au contraire, si des fois on en perd), c'est un gain de qualité (on a bénéficié des yeux d'autrui. On aurait certes mis moins de temps, mais on n'aurait peut-être aussi jamais pensé à faire ce changement), c'est du brainstorming perpétuel avec le monde, c'est de l'intégration de code, mais aussi d'humains (on espère toujours qu'un développeur de qualité finira par devenir dév core), etc.

      Bien sûr, de nombreux projets sont totalement irresponsables et "mergent" des bouts de code sans même les tester et en les lisant en diagonal. Github est notamment beaucoup responsable de cette logique. Perso je n'intègre jamais un nouveau code sans essayer de comprendre en détail ce que ça fait, pourquoi il faut changer, puis tester. En outre, on a en général une vision plus vaste du projet que les contributeurs occasionnels et c'est à nous que revient la charge de nous assurer que cela ne casse pas quelque chose d'autres auquel le contributeur n'a pas du tout pensé.

      Au final, oui le logiciel libre, c'est souvent l'apprentissage de la patience. On attend beaucoup. Mais faut comprendre que derrière, les gens ont aussi leurs propres priorités. Tu le dis toi-même d'ailleurs:

      Premier retour en une semaine et une demande de correction en un mois. Je traîne un peu et presque trois mois plus tard

      Dans ton cas, ils ont mis 1 mois pour te demander une correction, et tu mets 3 mois à leur répondre. Mais ils se sont pas plaints (et s'ils le font, c'est pas malin). Ils ont attendus. C'est normal, ça arrive. Ils savent aussi que les contributeurs ont aussi leurs propres priorités et ce n'est pas parce qu'ils ont fait un patch qu'ils vont répondre immédiatement aux demande de correction du dit patch.
      Des fois, on perd des patchs ainsi car ils ne reviennent jamais. Mais que peut-on y faire? Nous sommes prêts à les attendre, et on en attend autant des contributeurs envers nous.

      Donc oui, pour contribuer au logiciel libre, apprendre la patience et une forme d'empathie (pas de l'empathie émotionnelle, mais disons une sorte d'empathie sociale) fait clairement partie du processus. Le seul moyen d'y échapper est d'être le mainteneur sur tous ses projets et de ne jamais contribuer à un projet tiers.
      J'ai contribué en une dizaine d'années à des dizaines de projets. Certains patchs ont été rapides, certains ont pris des mois et des mois. Certains n'ont même jamais été intégrés, notamment j'ai des souvenirs de certaines fonctionnalités précises parmi mes premières contributions, avec des patchs envoyés sur des mailing lists (de projets actifs) qui n'ont jamais eu de réponse. Mais je sais que la faute est mienne car j'aurais dû insister (gentiment et poliment) mais à l'époque, je ne savais pas et ai abandonné.

      La contribution aux LL, ça se fait sur le long terme. Mais ce n'est pas grave. Au final je pense que j'ai apporté des pierres vraiment non négligeables à l'édifice du Libre et je suis vraiment content d'avoir appris ce jeu de la patience.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

    • [^] # Re: À propos des nouvelles fonctionnalités

      Posté par  (site web personnel) . Évalué à 3.

      Pour le coup, Spine-runtime n'est pas libre (et c'est bien dommage, j'aimerai beaucoup que Spine dans son ensemble soit libre ; enfin bref). Je ne dis pas que ton expérience (0 réponse de leur part) ne peut pas arriver avec un projet libre, mais pour le coup les auteurs n'ont pas l'air d'être des spécialistes du libre ; j'imagine que la disponibilité des sources est quelques chose d'apprécié par leurs utilisateurs, mais qu'ils ont une vision classique du développement de produit, et que la gestion des contribution n'est pas leur priorité.

      • [^] # Re: À propos des nouvelles fonctionnalités

        Posté par  (site web personnel) . Évalué à 2.

        Merci pour les retours d'expérience détaillées. Je n'ai plus envie de me battre pour que ma PR passe sur Express (projet qui a un prob de gouvernance en plus). L'idée de cette partie de mon post était surtout de faire un constat sur ce qui pouvait arriver. Je ne cherche pas à blâmer l'auteur (qui je crois est en burnout) mais à indiquer qu'un dév conséquent même bien fait n'aboutit pas toujours à une intégration dans le projet cible.

        Bref, je pense qu'on a encore de la marge pour améliorer le flux des contributions et savoir à quoi s'attendre !

  • # Fermeture de ticket automatique

    Posté par  (site web personnel) . Évalué à 1.

    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.

    Je trouve que c’est normal. Selon moi, « closed » signifie juste qu’un mainteneur du logiciel considère que le problème est résolu (s’il a commité avec “fix #1234” dans le message, c’est que c’est le cas). Ça ne signifie pas qu’il est dorénavant interdit de répondre sur le ticket. Si l’auteur du ticket considère que c’est pas vraiment corrigé, il suffit qu’il le dise à la suite de la discussion et réouvre le ticket.

    (Encore faut-il que le bug tracker permette à n’importe qui de ré-ouvrir un ticket, je sais pas si c’est le cas de github, mais en tout cas pour moi c’est une fonctionnalité importante.
    C’est d’ailleurs pour ça que je considère qu’un bug tracker doit être extrèmement souple et permettre à tout le monde de quasiment tout modifier dans un ticket, du coup je n’aime pas les bug trackers de github ou gitlab.)

Suivre le flux des commentaires

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