Bonjour,
Historiquement, Dolibarr est un projet qui se retrouvait virtuellement autour des sites Dolibarr, des forums et d’un dépôt de source (GitHub aujourd’hui). L’association est un support au projet, comme cela a été dit. Et comme toute association, Dolibarr fonctionne sur la base du bénévolat et de l’engagement (souvent peu visible) de beaucoup.
Le CA publie les comptes rendus de ses réunions, ainsi on peut voir ce genre de discussion le lendemain d’un débat au CA sur ce forum… On nous a soumis une question, le CA a cherché une solution qui s’est avérée plus complexe à mettre en place qu’il y paraissait. DOnc on va continuer à y travailler.
Plus généralement, il faut noter cette envie de participer à l’échange d’idées au débat, autrement que par forum, et perso, je le comprends. On vit la même chose dans la société, où on recommence à préférer la machine à café au bureau plutôt que le télétravail en pantoufles ou les réunions virtuelles par chat ou vidéo
Ces dernières années, l’association a lancé des journées Dolibarr (dolibardays), qui devraient aussi devenir des lieux d’échanges entre utilisateurs / partenaires Dolibarr. Rien n’empêche de le faire (il y a quelques années à Nancy s’organisaient de Doli’bar : réunion informelle d’échanges sur Dolibarr). maintenant c’est un dolibarrday) Il n’y a pas que les CA et AG de l’association pour éhanger sur Dolibarr.
Pour ma part je n’adhère pas à des associations « par intérêt (personnel) » mais parce-que la mission, l’objet, les objectifs de cette dernière m’importent … (SNSM, MSF, etc. et ce n’est pas non plus « pour réduire mes impôts lol »).
Dans le cas de l’asso dolibarr il y a quand même plein de bonnes raisons d’adhérer
La il y a peut-être une incompréhension, je crois de mémoire avoir « vu passer » des gens lors des devcamp pour quelques heures (des clients « locaux », des « anciens dolibarr », des « contacts techniques ») donc il ne faut pas hésiter à dire « j’ai envie de venir » …
Et encore une fois tout ça évolue, vos remarques, envies et souhaits de participer à des rencontres c’est bien, essayons de le faire, par exemple comme le dit @tiaris lors d’un doliday ou d’un évènement plus informel dans un 1er temps (rencontres « off ») et si la sauce prends ensuite de formaliser ça avec l’aide de l’association.
Exactement comme @tiaris parlait des doli’bar de nancy. Maintenant que covid est passé il faut re-créer ce qui fait la base d’un mouvement associatif: mélanger des humains, leur offrir un endroit d’interaction dans l’espace physique … certains disaient « avec une bière ça passe mieux »
Une piste: je suis dans le gard, j’ai des copains à Montpellier (@Lmag c’est pour toi…) il est probable qu’on essaye de faire quelques journées de co-working-dolibarr « entre nous » (le 1er la sem. prochaine) puis « on entre-ouvrira la porte » (si on trouve un endroit avec un peu de place) à des « dolibarr locaux » et si ça marche je pense qu’on se lancera dans une organisation dolibarrday mais peut-être plus sous la forme de dolibarr-dev-day que dolibarr-commercial-day selon notre sensibilité
Alors pourquoi pas essayer de faire ce genre de choses « autour de vous » ? Peut-être pouvez vous lancer un fil sur le forum « je veux interagir localement avec des dolibarr-dev ou des dolibarr-users à (nom de la ville) » qui est partant ? et ensuite lancez vous
Je suis certain que l’asso sera heureuse de soutenir l’étape 2 (communication, aide à l’organisation de l’évènement) car l’étape 1 est tout simplement impossible à organiser autrement que « localement »
Note: (en écrivant ces messages plein d’espoirs et d’idées je me place clairement dans le rôle d’un bénévole de l’asso.)
Bonjour,
Altairis est membre de l’asso et « preferred partner » depuis des années.
Je me suis déjà pas mal exprimé au fil des ans sur les axes d’amélioration que je vois pour l’association qui rejoignent pour certains ceux exprimés ici.
Il est clair que « pas de bras, pas de chocolat », ce qui signifie que si vous voulez améliorer le fonctionnement de l’association, sa communication, ses statuts, ses objectifs, il faut vous retrousser les manches et vous y investir.
Pour ma part, je n’ai pas cette énergie, ni forcément la diplomatie nécessaire…
J’essaye pourtant de temps à autres; j’ai été contacté il y a quelques mois par l’association pour envisager un Dolibarr Day suite à un message posté dans « la taverne », on me proposait d’en discuter lors d’une réunion, ce à quoi j’ai répondu favorablement… j’attends toujours l’invitation… ou plutôt je ne l’attends plus…
C’est un exemple parmi tant d’autres de points à améliorer mais je crois que la communication est le cœur du problème.
Et je suis peut-être bouché, mais l’absence d’utilisation de la visioconférence me laisse pantois; j’ai participé à un devcamp en 2019 et la partie « en journée » dédiée à des présentations s’y serait bien prêtée et aurait soulagé les finances des participants et de l’association. Pour la partie « en soirée » entre codeurs, c’est autre chose et je ne m’exprimerais pas sur ce sujet.
Il y a 15/20 ans d’années, je participais au développement d’un CMS (YACS) et nous avions des réunions hebdomadaires par chat, puis en visio quand Big Blue Button est apparu ! c’était utile, fructueux et peu onéreux…
My 2 cents !
Christophe
Le fait d’adhérer à l’association n’aura pas d’effet sur la vitesse de traitement des issues ou des PR. Car l’association à pour but la promotion (et non le développement au sens code) et l’outillage. Le développement reste purement communautaire.
Il y a une réunion par mois à l’association, avec une compte rendu chaque mois, même si il est loin d’etre détaillé.
Pour ce qui est de l’ AG, il faudrait en effet la faire en visio afin d’etre plus participative, cela me semble une bonne idée…
Pour les reste des échanges, l’asso s’inspire beaucoup du forum et des mails des adhérents pour orienter ses choix ou actions. Mais il y a une inertie forte… comme souvent dans les asso…
Le devcamp a toujours été ouvert à tous les développeurs. Mais cette année, comme il y a un nombre limité de place pour des raisons logistiques principalement, la priorité en terme de comm pour s’inscrire a été faite aux preferred partner en premier, comme chaque année. En général, il reste des places pour les autres qui sont ensuite invité via un message sur le site web + réseaux sociaux. Hélas le dernier a été un peu victime du succès grandissant du projet et malgré le fait qu’on ai poussé les murs pour attendre 30 participants malgré les limitations des hotels et salles, tout a presque été rempli dès le premier appel par les preferred partner. Il n’y a donc pas eu de relance pour les autres développeurs. Le devcamp a toujours été ouvert à tous les développeurs désireux de participer dans la limite des places dispo sur la base du premier réservé, premier servi (et sous réserve d’etre prêt à s’investir pour 4 jours). D’ailleurs, il y a à chaque session des nouvelles têtes qui se rajoute. Mais comme il y a très peu de turnover (ce qui est une bonne chose), le nombre de prétendant pour participer ne fait qu’augmenter. La décision a déjà été prise de limiter le nombre de participant par société pour résoudre ce problème au prochain devcamp et faire plus de place aux autres. Toutefois, cela reste un lieu d’investissement sur 4 jours. Pour es retours utilisateurs, on privilégie les échanges autour des doliday.
Une AG plus participative en visio me semble toutefois un axe de progession intéressant…
À ce propos comment se déroule l’ajout et la validation d’une contribution au projet ?
Il y a-t-il une revue de code sur les PR ?
Comment sont fait les tests de non régression ? Je n’ai pas vu de banque de tests fonctionnels sur github (ou alors j’ai mal cherché).
J’ai adhéré une année à l’association. Comme @ksar et @BB2A je m’attendais à y trouver un lieu de rencontre entre utilisateurs et développeurs. J’ai été déçue (et je n’ai pas renouvelé mon adhésion).
Pour contribuer à Dolibarr, je pourrais par exemple rédiger de la documentation. Ca tombe bien ce point est dans l’objet de l’association !
J’ai un peu écrit dans le wiki mais je suis très vite limitée par mes compétences.
Prenons l’exemple de la configuration des « Valeurs/filtres/tris par défaut » qui m’intéresse. Il y a régulièrement des questions sur le forum. J’ai dû remonter deux trois exemples dans le wiki, mais je ne peux pas faire plus.
Autre exemple le changelog. Il peut m’arriver de passer pas mal de temps pour trouver comment mettre en place une nouvelle fonctionnalité (parfois vraiment minime) qui m’intéresse. Ça peut être un casse tête de savoir quel module activer, où configurer la fonctionnalité. Par exemple, comprendre que pour accéder au module « base de connaissance » il faut activer « tickets » n’a rien de très intuitif. Pourtant base de connaissance peut avoir un intérêt en dehors de la gestion des tickets. J’imagine que je ne suis pas la seule.
On pourrait envisager que l’association anime ou stimule la mise en place de la documentation :
en favorisant une discussion entre utilisateurs bénévoles et développeurs pour éclairer les nouvelles fonctionnalités et permettre la rédaction d’un embryon de documentation
en structurant le wiki, par exemple en identifiant des pages qui doivent être créées, complétées
en sollicitant des utilisateurs sur le forum qui semblent a même de contribuer à ces pages
Déjà ce serait un plus ! Aussi pour permettre aux bonnes volontés de participer (et d’entendre leur frustration exprimée ici liée à la difficulté de participer).
Oui, je l’ai écouté, c’est très instructif et respectueux du parcours qui est difficile quand on veut porter les choses, c’est très clair, je pense pour tout le monde.
Regarder ce qui a été fait mérite respect et réflexion, mais ne fait pas avancer les choses. Il faut regarder devant être optimiste chercher dans la critique comment évoluer.
La proposition de @eldy serait déjà une bonne chose.
Ce qui est dit ici n’est pas de la critique pour critiquer, mais plutôt constructive !
Je suis le premier à donner mes contributions et je pense que @ksar allait dans ce sens aussi au vu ses contributions. Malgré le temps qui nous manque.
Les revues de code sont faites par qui le veut. De nombreux développeurs consultent les PR régulièrement et y mettent des commentaires. Après quelques temps, et même si il n’y a pas eu de retours de développeurs, il y a la revue de code du « mergeur » qui intégre la PR dans le code uniquement après sa review. Les tests de non régressions sont eux automatisés et exécutés à chaque PR soumise. Ils sont intégrés dans le projet meme, répertoire test/phpunit et sont exécutés avant même la revue du code des développeurs ou du mergeurs.
Bonjour à tous,
finalement ces échanges sont toujours intéressants, je trouve ça bien de pouvoir discuter de manière franche et transparente
J’ai decidé d’adhérer à l’association et payé ma première cotisation, comme dit plus haut parce que je pense qu’un logiciel gratuit et accessible est une noble cause, et qui peut aider nombre de petits entrepreneurs. S’il y avait une AG en video ce serait super +1
En tant que membre désormais, je n’ai qu’un feedback : les utilisateurs ne sont pas assez pris en compte! Notamment :
Ne serait-ce pas la mission de l’association de collecter du feedback?
De savoir quelles sont les fonctions les plus demandées par les utilisateurs?
Comment l’association fait-elle pour partager avec les developpeurs ce feedback qui a mon sens est essentiel?
J’aime Dolibarr et c’est un excellent ERP, évidémment rien n’est parfait mais le projet semble sain et dynamique. Ceci dit, pour augmenter les audiences il est tout à fait possible de le rendre plus user-friendly en donnant une place aux utilisateurs. On ne peut pas s’attendre à ce que les users « normaux » passent 4 jours en devcamp ou utilisent spontanément github pour remonter des bugs…
Pour affiner, je pense que Dolibarr requiert un minimum de connaissances pour être exploité pleinement, un élément que la communauté semble parfois un peu oublier, tant des choses qui peuvent leur sembler triviales ne le sont pas pour l’utilisateur moyen
dans les listes le total n’est pas toujours affiché, ou il n’est pas toujours possible de trier, et les changements sont faits mais pas toujours de manière systématique.
les nouvelles versions sont souvent plutôt des RC et tout le monde sait qu’il ne faut pas les télécharger: mettez-vous dans la peau d’un nouvel utillisateur…
pas de changelog dans la boutique, pas de notes, pas de politique claire de mise à jour etc (Je sais que ce sujet est en cours de discussion.)
je trouve aussi que les appels à contribution ne sont pas assez mis en avant, par exemple c’est bien de cotiser mais beaucoup d’apps font appel à des donations mensuelles. Il faudrait aussi expliquer concretement à quoi sert l’argent : développement de modules selon un système de vote???
Des propositions simples :
faire un questionnaire pour les usagers afin de noter Dolibarr, savoir ses forces et faiblesses perçues;
invitez des utilisateurs lambda pour votre prochain devcamp à faire une visio pour partager leur expérience;
introduire un système de vote de nouvelles fonctions comme sur microsoft ie un peu une wishlist pour les développeurs;
mettre en place une demande de dons pour quelques USD par mois.
Encore une fois je n’exprime qu’humblement mon opinion et suis tout à fait conscient que je ne connais pas tous les rouages de l’asso. C’est juste qu’en utilisant le soft tous les jours on s’en sent proche haha.
Et pour finir j’ai vu que sur le site la page d’installation pour Synology n’est pas dispo, je vais l’écrire
Merci pour ton adhésion. Même si il y a peu de plus value directe actuellement à être adhérent, la plus value est indirecte en permettant à l’asso d’agir plus éfficacement.
L’association s’occupe de la promotion uniquement (contrainte par statuts). Elle fournit donc les outils pour aider les échanges, mais l’animation reste fait par la communauté. Donc, par qui a le temps et la volonté. Les feedbacks sont actuellement collecté principalement:
par le forum
par les dolibarrday (qui sont des réunion développeurs - utilisateurs, voir plus loin)
En effet, tous les modules ne sont pas développés par les meme personnes. On ne peut hélas attendre que 100% du modules soit conforme et standardisé pour l’intégrer car c’est le fait d’avoir un module disponible dans le core qui fait que des développeurs vont l’améliorer. Attendre qu’un module soit parfaitement conforme signifie ne jamais intégrer le module et donc ne jamais avoir de développeurs qui vont le finaliser et par conséquent ne jamais avoir le module. On est pas sur un même contexte qu’un « éditeur de logiciel privé » qui définit une roadmap et paie des développeurs jusqu’à ce que le dev soit fait à 100%. On est sur un modèle de dev communautaire qui nécessite d’avancer par petite touche imparfaite et à de nombreux acteurs à chaque étape, pour mobiliser les personnes qui améliorent étape par étape la proposition précédente. Car ce sont les utilisateurs eux-meme (avec des compétences de dev, de documentation ou de traduction) qui améliorent l’outil. Il faut donc que ces utilisateurs aient sous la main ce qui est améliorable.
La standardisation est donc un chantier permanent et propre à un développement opensource « communautaire »…
Cela ne veut pas dire que la demande n’est pas prise en compte, bien au contraire: Les amélioration Dolibarr étant porté par des évolutions développé par les utilisateurs eux-même (ou via leur intégrateur), on obtient un ERP plus proches des besoins utilisateurs que la plupart des autres solutions. Cela veut par contre dire qu’il y a toujours des attentes pas encore traitées. Hélas, il y en aura toujours. On en a conscience, c’est pourquoi, on essaie d’avoir un rythme assez soutenu.
[/quote]
Même réponse que précédemment. On voit à chaque version que le nombre de cas comme cela a diminue. Mais la encore, il faut savoir attendre qu’une contribution vienne faire progesser le sujet. La généralisation des développements avec ModuleBuilder tend à voir ce point se réduire également (car la fonction tri/total devient alors native). Mais la transition prend du temps.
Les nouvelles versions ne sont publiés que quand il n’y a plus aucun problème « connu » bloquant ou majeur par les personnes qui testent et débugguent.
Cela n’évite hélas pas quelques bugs. C’est un des maillon faible du projet : Beaucoup trop de personnes participent à l’ajout de fonctionnalités (problème de riche) par rapport au nombre de personne qui participe à la phase debug (problème de tout le monde ;-), ce déséquilibre laisse passer quelques bugs en production. Ils sont en général vite remontés et corrigés. D’ailleurs, c’est souvent uniquement après la release qu’ils sont remontés (car les combinaisons de configuration et cas d’utilisation sont si nombreuses qu’en phase beta cel n’est pas vu). C’est en général le fait de passer sur un déploiement très large (on parle de centaines de milliers voir millions d’utilisateurs) que ce genre de problème apparait chez certains.
D’une manière général, le taux de bugs des release Dolibarr n’est pas plus élevé que d’autres projets de périmètre identique (on retrouve trente à quarante fix mineurs et 0 à 2 majeurs par mois, durant les 2 mois qui suivent, ce qui est dans les normes d’un projet de 1.5 million de lignes de code).
Les propositions pour bénéficier de plus d’aide durant les phase de beta (bien que plus longues que les phase alpha) sont les bienvenues car c’est honnêtement aujourd’hui le « point faible »…
Le changelog est généré est disponible avec la version. Pour chaque version. Il n’est techniquement pas possible de releaser sans avoir le changelog car sa génération fait partie du script de release.
Il est disponible dans la racine du projet.
La politique de release est défini ici:
[/quote]
En effet, l’expérience à montré que les fonds récoltés dans ce genre d’opération, sont très faible, même sur un projet très populaire comme Dolibarr, ou si faible (voir négligeable) que le temps investis pour mener ces opérations a plus d’effet quand il est investi ailleurs…
Le devcamp est une réunion uniquement de développeurs pour échanger pratique de développement. Inviter des utilisateurs dans ce cadre n’est donc pas adapté. C’est pourquoi, un autre type d’évènement est déjà organisé régulièrement par l’association pour cela. Il s’agit des DoliDay dont les buts est d’accueillir les utilisateurs pour ces échanges. Il n’y a pas encore de format « visio » car pour ce genre de retour, avoir 100 personnes en même temps est contre productif. Les DoliDay rassemble à chaque session une trentaine de nouveaux utilisateurs, ce qui permet déjà d’avoir une vision représentative.
C’est toujours super d’avoir des retours. L’exercice de réponse permet déjà de voir si oui ou non on a des réponses. Une absence étant un indicateur pour se remettre en cause. Une présence l’est aussi car si la réponse est sensé etre satisfaisante, si la question est posé, c’est qu’elle ne l’est pas tant que ça !
Attention, tout est à mettre en place. Il n’y a rien…
Il faut quelqu’un qui en veut, qui anime les réseaux avec plein d’idées à mettre en place pour faire connaître Dolibarr. Il aura toutes les clés en main.
