J’ai consulté les issues et les PRs sur le dépôt github de dolibarr. Je n’ai pas réussi à déterminer s’il y avait une procédure particulière pour l’assignation des issues, la publication des PRs etc.
J’ai vu pas mal d’issues corrigées qui n’ont jamais été assignées à quelqu’un, des PRs intitulés « FIX » qui ne sont reliés à aucune issue.
Si je veux participer et corriger des bugs, comment puis-je savoir si un bug n’est pas déjà en cours de correction ? Idem si un PR est marqué FIX mais non relié à un bug comment s’y retrouver ?
Néanmoins si vous vous attribuez un bug sur github un autre développeur ne devrait pas venir « marcher sur votre dev en cours » mais ça peut arriver … c’est aussi l’intérêt des devcamp dolibarr : c’est un moment où il est plus facile de coopérer / collaborer car la proximité fait qu’on se lève pour poser la question à un autre et réfléchir ensemble au pb…
La lecture de votre réponse laisse sous entendre qu’il n’y a pas réellement d’organisation en ce qui concerne la gestion des bugs et leur correction. J’espère me tromper.
pourquoi ? c’est un projet complètement communautaire, chaque contributeur fait ce qu’il veut et le propose ensuite pour être fusionné dans la branche principale du dépôt git.
en dehors de ça les autres actions qui existent sont centrées sur des appels à financements participatifs mais c’est généralement une société qui porte un projet (exemple la compta avec OpenDSI/Easya) …
il n’y a pas encore de « sous organisation » comme on aimerait le voir venir par exemple un responsable « GED » dans dolibarr qui organiserait les contributeurs qui souhaitent bosser sur ce sujet, un autre responsable « GPAO » par exemple ou « Formation » ou « moteur php » si on voulait « découper » le projet en couche techniques ou fonctionnelles …
je laisse d’autres développeurs s’exprimer mais c’est ainsi que j’observe le projet, « tiens j’ai du temps je regarde la liste des bugs du github, je m’accroche sur une issue et j’essaye de corriger ça » ou alors « je tombe sur un bug, je corrige, je fais une PR et … éventuellement je fais une issue pour en parler »
perso le seul point où ça me préoccupe vraiment c’est que parfois on a peu (trop peu) de doc / d’explications par rapport à une contribution et c’est compliqué de comprendre que ce qu’on aimerait faire était justement la situation de dolibarr 2 ans plus tôt et que « il a été décidé » de faire autrement … la impossible de trouver un espace d’échange qui permettrait de comprendre pourquoi le choix A était « mauvais » et le choix « B » était mieux
c’est - par exemple - ce qu’on a essayé de faire pour les factures de situations: documenter l’état actuel et pourquoi on change et comment on change, mais c’est vraiment un exemple très récent GIFF - Facture de situation 2022 - Dolibarr ERP CRM Wiki et c’est lié aux partenaires dolibarr
J’ai du mal à croire que Dolibarr se soit construit avec des contributeurs qui font ce qu’ils veulent chacun de leur côté.
Mais ceci explique peut être les incohérences que je découvre au fur et à mesure que j’explore le code source, comme par exemple des clés fk_pays qui pointent sur une table nommée llx_country, ou le terme produit qui se mue en product au gré des lignes de codes.
Pourquoi ce mélange de termes anglais / français ?
Autre chose, la dernière version semble être la 17.0.2 comme annoncé sur le site dolibarr.fr mais sur le dépôt github la dernière release est la 17.0.1
Désolé pour toutes ces questions, mais je cherche à savoir si ce projet peut répondre à nos besoins sur le long terme, et je cherche des infos sur la qualité du code et le suivi des bugs.
Pour le melange anglais-français, c’est un choix (malheureux?) que le project manager explicite ici par exemple :
Pour le reste, c’est une petite communauté de developpeur avec un très vieux code de base. Le problème, sur le long terme, sera la rapidité des nouvelles versions qui sortent : deux majeures par an.
Après, je suis assez d’accord sur le fait que la gestion des projets, des bugs et des pr est plutôt… a la bonne franquette, mais ça fonctionne tellement bien !
Tout s’explique mais le plus important c’est d’assimiler le fait que dolibarr existe depuis 20 ans + et sera encore la dans 20 ans.
Moi qui suis absolument fan du quadriciel laravel et qui me suis replongé dans dolibarr il y a ~5 ans après 10 ans+ de « simple utilisateur », je « peste » souvent contre les incohérences du code de dolibarr (dernière en date contrat vs contract) mais je crois que nous sommes tous dans la même situation, progressivement ça s’améliore quand c’est possible et que ça ne « casse » pas l’ensemble mais il faut faire avec.
J’aurais même envie de dire « ce qui différencie un vieux développeur dolibarr d’un nouveau » c’est … ça
Ce qui dépasse largement toutes ces considérations de « beauté du code » c’est que l’écosystème est assez dingue, il y a beaucoup de monde qui bosse avec et autour de dolibarr, des entreprises qui en vivent, des implémentations incroyables dans des situations très disparates.
Alors « welcome onboard » et comme le dit @DELTHAIR64 c’est souvent bien plus rapide et efficace de faire les premiers tours de roues avec un expert dolibarr !
Voila un sujet intéressant.
Il n’y a en effet actuellement pas de système de triage/attribution des bugs sur la partie des issues communautaires, car une correction de bugs prends quelques minutes ou heure dans le pire des cas, aussi il n’y a casiement jamais de collision la dessus (contrairement aux PR de features, venant de partout). Quand un développeur décide de corriger un bug, quelques instant après, une fois corrigé il est de suite soumis en PR, et le numéro de FIX est intégré dans la PR signalant automatiquement sa résolution ou la disponibilité du FIX en commentaire de la fiche du bug. Donc l’auto-assignation était très peu utilisé (d’où sa non disponibilité). Pour ce qui est de l’assignation pour autrui, le nombre de développeurs est de plus très important, rendant difficile de faire du triage qui ne soit pas contre-productif (par exemple sur quelle règle considérer que x est plus à même de résoudre que y, sachant qu’il y a plusieurs fois l’alphabet à gérer).
A l’expérience, il s’est avéré qu’ajouter une gestion d’attribution sur du FIX, sur un projet avec une communauté aussi active, n’apporte pas grand chose en terme de productivité (même lorsque le travail de l’aiguilleur est faible), et le pragmatisme a naturellement pris le dessus.
Un autre point est que souvent, ce n’est pas depuis l’interface communautaire qu’une société va reporter et suivre ses bugs mais via son intégrateur qui, lui, adopte une politique convenue avec son client (souvent en utilisant sa propre interface). On est alors dans les cas de FIX soumis par l’intégrateur sans bug déclarés dans l’interface publique. Ce « libéralisme » est le genre de petites différences de fonctionnement que Dolibarr a, comparé à d’autres projet, mais c’est aussi ce qui explique que son taux de traitement de PR et de FIX soit supérieur aux projets traditionnels de taille équivalente.
Il serait intéressant, pour aider le projet à progresser, d’avoir des pistes sur ce qui a orienté la décision… si ce n’est pas confidentiel bien entendu.
L’objectif est d’utiliser le même logiciel pour gérer plusieurs filiales réparties dans divers pays (c’est disparate actuellement et cela complique énormément le suivi opérationnel)
On a commencé les tests en début d’année, et il faut être opérationnel pour janvier 2024.
Une des contraintes c’est la gestion des taxes aux USA. D’où l’analyse du code source pour voir si on peut développer notre solution de gestion des taxes en interne, et adapter dolibarr à d’autres besoins spécifiques.
Au final le choix s’est porté sur zoho (on a étudié sept solutions différentes), Dolibarr aurait sans doute été choisi parmis les solutions open source.
