Libres conseils
Highlights
3. Hors du labo, au grand air
Plus il y a d’utilisateurs, plus il y a de bogues.
3. Hors du labo, au grand air
Le pluriel d’« utilisateur » n’est pas « communauté ». Si les premiers peuvent voir leur nombre s’accroître, la seconde ne grandit pas d’elle-même, ou alors elle grandit sans direction et surtout sans fournir le soutien espéré au projet. La mission du responsable de projet qui cherche à profiter de l’énergie brute des utilisateurs ressemble à celle d’un jardinier qui doit préparer un terrain fertile, planter et arroser les semis, et peut-être élaguer les pousses non désirées avant de pouvoir récolter les fruits. Par rapport aux récompenses qui viendront, l’investissement global est minime, mais il est essentiel de faire les bonnes choses, au bon moment.
3. Hors du labo, au grand air
Les responsables du projet se doivent de fournir des espaces de communication afin que la communauté puisse se développer. C’est un service banal mais souvent négligé. Sans liste de diffusion dédiée, toutes les demandes d’aide seront envoyées en message privé à la maintenance. Sans logiciel de suivi des problèmes [2], les rapports de bogues seront moins nombreux et moins utiles. Sans un wiki où tout un chacun pourra modifier la documentation utilisateur, le développeur est condamné à étendre et à réécrire la documentation en permanence
3. Hors du labo, au grand air
Pour attirer aussi bien des utilisateurs que des contributeurs, il faut faire passer le mot. La communication publique d’un vrai projet devrait au moins inclure des annonces à chaque nouvelle version. Les listes de diffusion sont probablement le meilleur canal pour cela. Il faut un certain talent social pour trouver le juste équilibre entre le spam indésirable et la litote timide. Si un projet est motivé par la conviction sincère qu’il aidera les utilisateurs à résoudre de vrais problèmes, ce devrait être facile de lui faire une publicité convenable. Les utilisateurs feront vite la différence entre publicité éhontée et information utile.
3. Hors du labo, au grand air
Bien évidemment, les annonces actives devront attendre que le projet soit finalisé. Cela ne concerne pas seulement le code, mais aussi la page d’accueil et la documentation pour une utilisation basique.
3. Hors du labo, au grand air
On ne rendra jamais suffisamment grâce au pouvoir du simple lien qui conduira un futur contributeur important à sa première visite sur le site du projet. Les chercheurs ne doivent pas non plus oublier de publier leur logiciel en dehors de leur communauté universitaire proche
3. Hors du labo, au grand air
Les développeurs inexpérimentés sont souvent inquiets à l’idée que l’ouverture de listes de diffusion, de forums et de wikis pour les utilisateurs nécessitera une maintenance supplémentaire. C’est rarement le cas mais certaines activités de base sont bien entendu indispensables. Cela commence par la mise en œuvre d’une communication publique et son utilisation rigoureuse. Les utilisateurs ont besoin d’apprendre à poser des questions publiques, à consulter la documentation avant de poser des questions, et à rapporter les bogues à l’aide d’un logiciel de suivi des problèmes plutôt que par courriel
3. Hors du labo, au grand air
Dans tous les cas, les utilisateurs doivent être remerciés explicitement pour toutes les formes de contributions : il faut beaucoup de personnes enthousiastes et bien intentionnées pour construire une communauté solide.
3. Hors du labo, au grand air
Quand on atteint un certain nombre d’utilisateurs, une aide mutuelle commence à se mettre en place entre eux. C’est toujours un moment magique pour un projet et c’est un signe évident qu’il est sur la bonne voie. Dans l’idéal, les responsables du projet devraient continuer d’apporter leur aide pour les questions délicates, mais à un moment donné certains utilisateurs vont faire preuve d’initiative dans les discussions. Il est important de les remercier (personnellement) et de les impliquer davantage dans le projet. À l’inverse, les évolutions malsaines doivent être stoppées dès que possible, en particulier les comportements agressifs qui peuvent être un véritable danger pour le développement de la communauté
4. Préparez-vous pour le futur
Le revers du relais générationnel dans un projet libre peut apparaître sous une forme très concrète, à savoir un fossé de connaissances. Quand un ancien développeur quitte le projet, et particulièrement s’il avait une expérience approfondie dans cette communauté, il laisse derrière lui ses connaissances aussi bien concrètes qu’abstraites, qui ne sont pas forcément transmises aux nouveaux venus [6].
4. Préparez-vous pour le futur
Passez du temps à développer les principales lignes directrices de votre projet. Cela peut commencer par un seul et court document, qui détaille simplement des recommandations et des bonnes pratiques. Cela devrait évoluer à mesure que le projet grandit et permettre aux nouveaux arrivants tant de saisir rapidement les valeurs principales de votre équipe, que de comprendre les traits principaux de votre méthodologie.
Forcez-vous à suivre des standards de codage, des bonnes pratiques et un style élégant. Documentez votre code. Insérez des commentaires pour décrire les sections qui seraient particulièrement difficiles à comprendre. Ne pensez pas que c’est du temps perdu. En fait, vous faites preuve de pragmatisme en investissant du temps dans l’avenir de votre projet.
Dans la mesure du possible, lorsque le moment vient pour vous de quitter le projet, essayez d’avertir les autres de cette décision longtemps à l’avance.
4. Préparez-vous pour le futur
Assurez-vous toujours de laisser assez d’astuces et de commentaires pour qu’à l’avenir un nouvel arrivant puisse s’approprier votre travail.