Si vous voulez gardez vos bêta-testeurs...

Un petit retour sur les quelques expériences que j’ai eu lors d’échanges avec des développeurs.
Ce billet fera suite à celui sur le maillon manquant mais en l’étendant à la plupart des projets.

Comme il est souvent dit à propos de comment contribuer pour les projets libres autrement qu’en codant, un élément important est de tester afin de découvrir des bugs ou faire des suggestions d’amélioration à l’équipe de développement. Je ne prendrai pas de cas particulier mais il m’est arrivé parfois de signaler des problèmes ou de proposer de nouvelles fonctionnalités et je vais tenter de vous décrire comment j’ai vécu la chose.

D’abord, il faut avouer que souvent le premier retour est plutôt positif, "merci de l’intérêt pour notre projet" et je n’ai jamais eu de fin de non recevoir mais la seconde partie est souvent beaucoup plus mitigée. Si on propose une fonctionnalité sur un logiciel dont l’auteur est sur autre chose, il nous invite gentiment à le faire par nous-même, j’aurais parfois bien aimé mais même si j’ai déjà écrit du code dans une autre vie (et d’autres technologies), j’ai vite perçu mes limites et cela ne m’intéresse plus.

Une autre réaction que j’ai déjà eu, c’est "ah oui, cette idée là est sympa, je la prendrai en compte pour les futurs développement (cool), par contre, cette idée là, non, il n’y a aucun intérêt de pouvoir faire comme on veut, tout le monde doit faire comme j’ai choisi" alors que la fonction existait ou existe sur d’autres applications. Et c’est là où l’on se dit que le développeur dicte un peu la façon dont il veut que l’utilisateur se comporte.

Pour ce qui est des bugs, c’est souvent pire. Lorsque l’on fait un gentil mail, la première chose que l’on nous dit, c’est qu’il faut passer par le tracker, le forum ou tout autre outil que le projet a choisi. Bon, gentiment, on va donc s’inscrire sur le truc en question, on doit souvent faire des manip supplémentaires pour récupérer les logs, passe encore (mais pas à la portée de tout le monde en général) et après, on apprend que le bug est, soit déjà répertorié, non fondé ou, bien souvent, dû à l’architecture/l’environnement sur lesquels on tourne. Bref, cela ne marche pas mais ce n’est pas la faute du projet, donc à nous de changer de machine ou de remonter le bug au niveau de l’environnement ou de la distro.

Le dernier cas, c’est que le problème rencontré est gentiment ignoré. Sans doute le plus frustrant.

Bref, la plupart de mes tentatives se sont avérées peu probantes et j’y vois principalement deux problèmes :

• les systèmes de report de bug sont souvent imbitables. Qu’ils soient utiles aux développeurs pour hiérarchiser les priorités et voir où en sont les résolutions, j’en suis persuadé mais pour l’utilisateur quelconque, c’est quelque chose de totalement incompréhensible, souvent en anglais, avec un classement totalement obscur pour quelqu’un qui ne connaît pas le projet, avec toutes les chances de ne pas décrire correctement le bug ou de faire des doublons.
• un manque de rapport direct avec quelqu’un qui connaît le projet, est au courant des problèmes connus, peut aider à mieux définir le problème et faire un minimum de retour sur la possibilité ou non de faire avancer le problème.

Et à ces problèmes, je répète ce que j’ai déjà dit à ce sujet sur le projet Firefox OS (Monsieur BORNE, je vous entends ricaner au fond de la classe), il manque un maillon : l’humain qui fait interface entre l’aspect technique et les utilisateurs, qui est capable de gérer les rapports de bug à partir de n’importe quel échange (téléphone, mail, irc, forum ou réseaux sociaux), qui peut dire : ça c’est dans les tuyaux, ça c’est connu, ça ce n’est pas possible ou ça c’est une bonne idée.

Souvent, c’est le cas lorsque les projets sont petits et reposent sur une seule personne et c’est là où je rejoins Cyrille qui a besoin de ce contact humain et direct et qui justement ne fait des retours et de contributions que pour ce genre de projets.
Mais pourquoi n’est-ce plus possible lorsqu’un projet grandit ? Forcément, cela demande de la communication avec les différents développeurs et d’être disponible pour les utilisateurs, d’être capable de se mettre à leur niveau et comprendre leurs problèmes ou besoins. Bref, faire du réseau social quoi !
Ah bon ça veut dire autre chose que mâter des vidéos de chat et s’étriper pour savoir qui est le plus fâcho ?