Et ensuite on s’étonne que l’on ne trouve pas de béta-testeur…
A chaque version majeure, je passe près d’un mois à tester mes modules, quand j’ai la chance d’avoir une personne en stage qui me donne un coup de main, bizarrement moins elle est compétente, plus elle me trouve des bugs…
Se passer de ses personnes au motifs qu’ils ne soient pas familier avec github est dommageable, une fois de plus on se retrouve dans une logique condescendante qui clairement ne motive pas à s’impliquer.
Je persiste à penser (et écrire) qu’un minimum d’écoute et de compréhension des utilisateurs, intégrateurs ferait grandement avancer les choses. Ma grand-mère disait que ce n’était pas avec du vinaigre que l’on attirait des mouches… si l’on souhaite avoir des testeurs et des utilisateurs, il faut clairement leur « macher » le travail, en mettant à disposition une plateforme de tests des versions béta
Je me demande d’ailleurs si on ne pourrait pas proposer des clouds de migration en version béta pour permettre de tester leur prod sur la nouvelle version et au travers de cette environnement de remonter des anomalies (en plus avoir accès à leur log…).
« Le choix d’acheter une voiture de sport dès l’obtention de son permis de conduire relève de choix personnel ou d’exploitation »
Bonjour
Merci @eldy pour la réponse précise et complète… comme d’habitude !
Je nuancerai toutefois celle-ci par deux aspects :
Administrateur de Dolibarr pour mon entreprise depuis 10 ans, j’ai découvert ce lien vers le gestionnaire de bug à l’instant… Trop habitué sans doute à aller uniquement et directement sur les pages qui me sont nécessaires… Mea culpa !
Le gestionnaire de bugs est github. Je parle anglais, mais je n’ai pas encore compris comment tout cela fonctionne et comment je peux y contribuer efficacement (je rejoins @hop).
En pratique et en conséquence, je ne travaille jamais (exception faite pour la 19 : je suis disponible en ce moment !!!) sur les versions x.0.0. Je m’intéresse toujours aux révisions 1, 2 ou plus.
Quand je trouve quelque chose qui ne fonctionne pas (bug ou pas : je ne sais pas toujours le définir…) je poste sur le forum après avoir fait quelques recherches… et j’attends… parfois avec succès, parfois sans.
Tout cela ne doit pas nous faire oublier de souligner la grande qualité du travail effectué sur Dolibarr et de remercier chaleureusement tous les contributeurs.
J’ai parfois honte de ne pas pouvoir mieux contribuer moi aussi…
Francis
La période de correction (date de release prévu → plus de bug connu) devrait avoir son zip aussi avec un build journalier pour permettre aux non-dev de tester pendant cette phase.
Pour déclarer un bug sur github, il faut juste savoir remplir un formulaire en ligne (On clique sur le bouton « Soumettre une nouvelle issue » puis il n’y a que 2 champs obligatoires: Un pour le titre et un pour la Description) puis le bouton « Soumettre ». C’est fini.
Aucune connaissance particulière n’est donc nécessaire. Du coup, le nombre d’utilisateurs « exclut » est vraiment limité au minimum (on pourra pas faire plus light). Sinon, pour être honnête, vu le nombre d’utilisateurs, on ne manque pas de testeurs (attention, certaines personnes propagent régulièrement de la désinformation sur le forum, il est de la vigilance de tous de vérifier les affirmations de chacun qui n’engagent qu’eux), on manque plutôt de « correcteurs de bug » (donc profils dev avec les compétences et le temps pour corriger ce qui est déclaré sur le bug tracker).
Pour info, il y a un build de zip qui n’est pas journalier mais temps réel disponible depuis la page Télécharger du site web de Dolibarr, dans la section « Version develop ou beta ». Ce lien pointe sur la beta quand on est en phase beta, mais quand la release est sortie (donc plus de bug critique connu), il pointe vers la version de dev.
En l’état actuel des choses tout fonctionne bien finalement, en tant que non développeur mais après avoir galéré sur des .0.0 j’attends les .0.3 ou .4. Qui sont de fait des versions utilisables où il n’y a pas de bug bloquant.
Le problème est plus pour moi que tous ceux qui savent comment fonctionne Dolibarr traitent les premières moutures comme des bêtas, mais ceux qui ne savent pas les installent et vont forcément avoir une très mauvaise première image de Dolibarr (installation> problème> forum> “tu n’avais qu’à pas l’installer, tout le monde sait qu’il ne faut pas”> ).
Par ailleurs les bugs sont bien remontés sur ces versions et sans passer par GitHub non?
Ensuite à ma connaissance il n’y a jamais de version .1, n’est-ce pas un peu bizarre de ne faire que des .0.x?
Je pense que pour les utilisateurs lambda comme moi la bêta devrait être une alpha et nous ne la voyons pas, ensuite 19.0.0 deviendrait 19 bêta, puis l’équivalent de 19.0.2 deviendrait 19.0 ou 19.1 Cela ferait plus de sens, car beaucoup d’utilisateurs sont habitués à prendre des risques sur bêta (merci Google), mais il faut juste le dire clairement car dans ces versions il n’y a pas non plus de problème insurmontable.
Pour moi les utilisateurs Dolibarr sont forcément un peu technophiles, ils comprennent (nous comprenons) si on leur dit les choses clairement.
Dans la mesure où une mise a jour est souvent plus risqué qu’une nouvelle installation, on pourrait imaginer un verrou ou disclaimer dans le cas où le conf.php a la constante de prod sur 1, et eviter une maj sur une version x.0.0
Ainsi au moins pour des utilisateurs +/- lambda l’info serait adaptée
I think you’re missing a point here: issues have to be reported in english, and the whole github website is only available in english.
Given the activity on the various Dolibarr forums, the vast majority of users are French-speaking.
That’s why bugs are mainly reported on the forum, and not on github.
Je suis d’accord avec toi que ça peut en rebuter quelques uns. Personnellement, je me sers de google traduction pour aller plus vite, et c’est assez juste la plupart du temps.
Bravo, tu as été plus loin que prévu apparemment puisque tu as même été jusqu’à apporter une correction clé en main via git ! Y a plus qu’à attendre les retours ou le merge direct si tout est ok…
Et @eldy tu vois que d’en parler sur le forum permet à des gens de devenir vraiment contributeurs directs… je suis persuadé qu’il faut être sur le forum, à l’écoute et montrer que c’est possible.
Forum → git → PR → « compte rendu sur forum » et ensuite quelques mois / années plus tard « sav » grâce au forum on retrouve les échanges qui ont menés à une solution ça me semble vraiment être le combo gagnant pour créer du lien entre tout le monde et impliquer la communauté au sens large
Je me suis mal m’exprimé si j’ai laissé croire que je pensais que le forum ne peut pas servir à mobiliser des contributeurs. Ce que je voulais dire c’est que chaque outils est adapté à un publique et à un périmètre d’action, et que, si un outil est utilisé pour aborder un périmètre qui est mieux traiter par un autre outil (exemple forum vs github), il vaut mieux orienter l’usager sur cet autre outil, plutôt que d’insister à vouloir utiliser absolument le premier pour réussir à répondre au sujet. C’est parce que je crois en l’intérêt de chaque outil que je consulte aussi bien le forum, que git, que le discorde, que les réseaux sociaux. Mais à titre personnel, j’y répond différemment, car je préfère réorienter dès qu’un échange me semble plus pertinent d’être couvert par un autre outil plutôt que de répondre directement car cela créé alors trop de doublon entre les outils…
En tout cas, bravo @Le_Reparateur , tu viens de faire gonfler les stats du nombre de contributeurs différents, ta PR ayant été mergée…
).
et impliquer la communauté au sens large
