Bonjour, je ne veux pas spécialement rajouter de l’huile sur le feu, mais la question de l’infra utilisée en milieu open source est réelle et les frustrations que ça crée des deux côtés du problème sont récurrentes et importantes à traiter.
Cette année au FOSDEM, il y a eu la conférence sur la gouvernance logicielle des FOSS, qui est dans un contexte assez politisé autour du copyleft mais qui rappelle aussi cette problématique : FOSDEM 2025 - The Growing Body of Proprietary Infrastructure for FOSS Development: Repeating Bad History
De mon côté, le principal de mon temps est principalement passé sur VideoLAN, qui a eu le même type de question et qui essaye de favoriser du 100% FOSS (gitlab autohébergé, framapad, etc). On a typiquement régulièrement des contributeurs qui nous demande d’ouvrir les demandes de merge sur github, et le fait de ne pas le faire a un certain coût en terme de contribution. Mais c’est aussi la mission de l’association de valoriser les outils et infrastructures open source et ne pas en dépendre, ce qui pour nous est d’autant plus important quand on voit les exemples de logiciel comme yt-dlp/newpipe qui ont régulièrement été supprimé de github.
Maintenant, l’importance donné à ce sujet dépend surtout des membres de l’association Dolibarr (dont je ne fais pas parti) et c’est à vous de rendre ce cadre clair. Si l’association décide que choisir linkedin n’entrave pas sa mission (par exemple parce que c’est limité à de la communication, ou parce que c’est pas le sujet), ça clôt le sujet de façon clair pour tous. Et sinon il faut effectivement choisir un autre outil dès lors que l’on veut réellement participer à la même mission que l’association, ce qui personnellement me parait raisonnable pour un GIFF communautaire.
Après pour cette problématique en particulier, j’adore le fait que du travail soit réalisé autour de ces points. J’apprécie également la communication qui en est faite. À mon sens, une formalisation de ce qui marche et ne marche pas dans l’UX actuelle est réellement importante pour l’avenir de Dolibarr.
Maintenant, si le but est de présenter des screenshots et demander des votes, j’ai un peu peur qu’on perde l’aspect UX comme dit précédemment par d’autres. Bien sûr, il ne s’agit que d’un avis, à prendre comme tel et à utiliser ou à jeter. Mais à mon sens, il y aura un bien meilleur impact si le groupe travaille avec des gens qui déploient Dolibarr en coopérant avec des entreprises, en mettant en place des vrais changement d’UX directement pour des gens qui l’utilisent et en recueillant des témoignages d’utilisateurs précis via ces entreprises (avec une multitude de point de vue sur l’outil) plutôt qu’en laissant tout le monde répondre à des sondages.
Ça demande probablement des changements dans le coeur de Dolibarr et un peu plus de travail pour effectivement déterminer ce qui va marcher ou pas, mais ça permettra d’éviter de faire décider les micro-choix d’UX et de design par les utilisateurs lambdas et les développeurs, qui aurait chacun eu leur propre avis non-cohérent bien entendu, et donc garder la compétence là où elle doit être valorisée, et permet par la même occasion d’améliorer la partie coeur de Dolibarr en ciblant les points de blocage techniques pour qu’ils soient résolus par le reste de la communauté.
De mon point de vue, c’est ce que vous faites avec « Etape 1 » lors de la réunion du 05/07/2024. Mais le reste de la communauté ne participant pas au GIFF n’a pas forcément besoin du détails en temps réel de chaque question d’UX tant qu’elle n’est pas mise en expérimentation, et c’est surtout le compte-rendu qui va compter.
Pour prendre un exemple extrême où la quantité de préparation publique est de zéro, l’engouement autour du projet de @John_BOTELLA (Nouveau module Thunderbird connecté à Dolibarr : Gratuit et Open Source) permet directement de se poser des questions sur le type d’expérience qui est favorisée et qui en bénéficie, pour pouvoir apporter des propositions sur l’interface vanilla du logiciel pour eux, sans avoir besoin d’un mockup completement fini en demandant à la communauté à chaque étape si chaque fonctionnalité est nécessaire. L’ensemble du module ne peut pas être développé de cette manière, mais pouvoir le mettre dans la main des utilisateurs et voir ce qu’ils en disent sans intervenir c’est la base du playtest et pouvoir le mettre en production directement chez les personnes qui vont l’utiliser, en ciblant donc précisément l’utilisateur final et en le sélectionnant pour être certain qu’il soit coopératif et pouvoir avoir un retour pertinent de si ça améliore leur expérience ou nuit à d’autre me semble plus efficace et pertinent.
