Bonjour.
Vous m’avez devancé. J’ai écouté ca il y a pas tres longtemps. Très interessant.
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 
Des exemples :
- Au niveau du code, on dirait que chaque module n’est pas validé de manière standard Current ODT template support · Issue #14818 · Dolibarr/dolibarr · GitHub. Perso ça m’a pris des heures voire des jours pour pouvoir contourner ce problème d’absence de pdf dans le module tickets.
- 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 
5 « J'aime »
Si tu as besoin d’un coup de main …
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 !
Yes yes yes… Merci pour ton aide…
7 « J'aime »
Bonjour,
Septembre est disponible.
Fiche de poste-community manager - Dolibarr ERP CRM Wiki => A suivre
2 « J'aime »
Bonjour 
Ca me dirait bien tiens community manager chez Doli 
Bonjour,
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.
La fiche de poste sera publiée prochainement.
Excellente journée
2 « J'aime »
Bonjour,
C’est bien un poste de bénévole ? Ou l’association arrive à financer des emplois à l’année ? 
Bonsoir,
Non, nous visons un poste financé.
Excellente soirée
Bonjour,
Le rapport de décembre est disponible avec pas mal de nouveautés :
- Un nouveau membre au Board
- On pourrait peut-être avoir le droit à une AG
, même si il manque une solution technique : actually foundation have 152 valid members, what happens if we have every body in visio, which technicals solutions can support the numbers of attendees - Créations de Commission
2 « J'aime »
Dans ce cas de figure la solution souvent retenue c’est une diffusion en direct de l’événement, et les questions des participants à distance sont transmises par un système de chat.
1 « J'aime »
Bonjour,
Sur le sujet des commissions le draft de proposition de fonctionnement proposé à l’asso rédigé avec @Lmag Olivier Tourvieille et moi-même.
1 « J'aime »
Bonjour @pscoffoni je viens de m’inscrire.
comment fait on pour participer à une commission / assemblée ?
j’aimerais être dans la commission communication.
1 « J'aime »
Nous sommes tout juste en train de tester l’outil decidim, il faut prendre le temps de se plonger dans la documentation pour tout bien maîtriser et ça demande un peu de temps 
Pour chaque commision/projet il y a normalement un responsable qui est le référent.
On va expérimenter cet outil Commission Communication - Decidim pour Dolibarr
qui sera internalisé par l’asso s’il convient. Tu peux t’inscrire dessus. On va organiser une visio prochainement pour commencer à préparer une proposition de commission pour l’asso.
2 « J'aime »
Bonjour Philippe,
Je me suis inscrit avant même ta réponse.
Comment sera t’on informé de cette prochaine visio ?
Cordialement
Christophe
2 « J'aime »
