La question des bonnes pratiques au sein d’une communauté

image_pdfimage_print

Sarah Sharp, dont nous avons traduit récemment le billet d’adieu à l’équipe du noyau Linux ne se contente pas de pointer ce qui dysfonctionne dans les rapports humains au sein des équipes de développement. Elle propose ici toute une série de bonnes pratiques, selon elle nécessaires, qui visent à améliorer la qualité des échanges quotidiens, du moins à rendre vivable et acceptable le travail ensemble.
Il est certain qu’une liste aussi copieuse peut surprendre, et même être rejetée d’un haussement d’épaules au motif que c’est typique du « politiquement correct » à l’américaine… Cette longueur et cette précision s’expliquent sans doute par l’expérience désagréable de Sarah : les situations qu’elle a vécues lui ont imposé d’aller bien plus loin qu’un simple code de conduite, qui sert trop souvent d’alibi aux communautés.
On trouvera donc un peu de tout dans ces recommandations classées par étapes progressives : du simple bon sens dont on s’étonne qu’il soit nécessaire de le formaliser (mais justement ce bon sens ne va plus de soi, parfois), mais aussi des vues très pertinentes sur le fonctionnement optimal d’une communauté qui rappellent l’ouvrage de Karl Fogel Produire du logiciel libre (un Framabook !).
Ces propositions, malgré leur caractère un peu idéaliste, nous amènent à interroger nos pratiques, car les communautés libristes, si elles sont loin d’être des champs de bataille, sont rarement de longs fleuves tranquilles.

Qu’est-ce qui fait une bonne communauté ?

Billet original de Sarah Sharp publié sur son blog : What makes a good community

sarahSharpTwitterImage
Photo © Sarah Sharp licence CC-BY-NC-SA

Parvenir à faire vivre une communauté hétérogène est un processus progressif. Il n’existe pas de raccourci. En ce qui concerne le changement culturel, chaque niveau doit être atteint avant de passer au suivant. Il vaut également la peine de préciser que chaque étape doit bénéficier à l’ensemble des membres de la communauté et pas uniquement à quelques contributeurs.

Niveau 0 : respect fondamental de l’humain

Pour pouvoir attirer des participants très divers, vous devez avoir la réputation d’être une communauté accueillante, régie par une série de règles sociales explicites et acceptées. Il ne suffit pas d’avoir un code de bonne conduite. Ceux qui pilotent la communauté doivent le soutenir et il doit être imposé.

Une communauté accueillante de niveau 0 fait preuve des caractéristiques suivantes :

  • chacun est encouragé à faire des retours sincères et directs sur les questions techniques ;
  • les contributeurs sont invités à résoudre les conflits entre personnes de manière saine ;
  • les interactions quotidiennes dans la communauté sont généralement au niveau DISCON 1(*) (c’est super, tout va bien), et tombent occasionnellement au niveau DISCON 2 (insultes non personnelles) ou DISCON 3 (utilisation de grossièretés) ;
  • les contributeurs qui atteignent régulièrement le niveau DISCON 4 (insultes personnelles) sont encouragés à modifier leur comportement ;
  • les contributeurs qui atteignent le niveau DISCON 5 (menaces) sont fermement invités à cesser leur participation ;
  • les harceleurs récidivistes sont exclus des conférences et bannis des réseaux de discussion ;
  • les petits nouveaux et petites nouvelles sont informé.e.s sur les « brebis galeuses » et sur les personnes dont les retours sont sans intérêt ;
  • un code de conduite explique clairement quels sont les comportements encouragés et les comportements dissuadés ;
  • dès que de petites hostilités apparaissent, les membres de la communauté arrêtent ce qu’ils font, écoutent et s’excusent ;
  • la communauté dans son ensemble, y compris les responsables et les community managers, fait respecter les normes de communication.

Niveau 1 : embarquement

La phase suivante pour améliorer la diversité est de comprendre comment embarquer de nouveaux passagers. Si seulement entre 1 et 10 % des nouveaux venus ont une personnalité originale et que 90 % des personnes sont boulées dès leur première contribution, eh bien, vous ne pouvez pas espérer que toutes sortes de gens adhèrent à la communauté, n’est-ce pas ? Il est donc essentiel d’expliquer le mode de fonctionnement implicite de votre communauté, de sorte que les candidats de toute origine (qui sont souvent effrayés à l’idée de bouleverser l’ordre établi) sachent où ils mettent les pieds.

Dans une communauté accueillante de niveau 1, on trouve :

  • une documentation précisant par quels moyens interagir avec la communauté (irc, liste de diffusion, suivi des tickets (bug tracker), etc.) ;
  • des réunions dans la vraie vie pour encourager le travail en réseau avec les nouveaux membres ;
  • des discussions par vidéo ou en direct pour mettre un visage sur les noms et encourager l’empathie et la camaraderie ;
  • une documentation de base concernant les contributions relatives à la compilation, au fonctionnement, aux tests et au perfectionnement ;
  • un système de tests facilement accessible sur le Web pour les nouvelles contributions ;
  • des tutoriels détaillés et maintenus à jour ;
  • un guide de bonnes pratiques pour le code (ce qui est demandé, ce qui est facultatif et qui écouter quand il y a un désaccord entre les développeurs) ;
  • le planning des sorties (les releases des produits) et des dates-limites pour ajouter des fonctionnalités ;
  • des moyens pour faire un retour sur les contributions ne concernant pas le code (rapport de bug, documentation, tutoriels, tests, planification d’événements, graphismes).

Niveau 2 : contributions significatives

L’étape suivante consiste à savoir quoi faire de ces nouvelles recrues motivées. Si elles sont arrivées là en dépit d’une culture technologique malsaine, il y a de grandes chances pour qu’elles soient persévérantes, intelligentes, et à la recherche d’un défi. Si vous n’avez pas de vastes projets significatifs auxquels elles pourraient contribuer, elles s’en iront vers des cieux plus brillants.

Dans une communauté accueillante de niveau 2, on trouve :

  • des listes de tâches réservées aux nouveaux ;
  • de gros projets indépendants ;
  • des mentors accueillants et disponibles ;
  • des programmes pour payer les nouveaux venus (des stages, un summer of code, etc.) ;
  • des contributeurs chaleureusement remerciés, avec la reconnaissance explicite de ce qui a été réussi et de ce qui pourrait être amélioré ;
  • un canal de communication informelle pour trouver des idées avec les nouveaux (irc, liste de diffusion… n’importe quoi tant que ça fonctionne) ;
  • un code de conduite qui encourage les développeurs à être animés de bonnes intentions.

Niveau 3 : accompagnement

L’étape suivante pour une communauté, c’est de se demander comment retenir de nouveaux participants très divers. Comment allez-vous promouvoir ces nouveaux profils originaux afin de leur permettre d’avoir un impact sur la communauté au niveau de la gouvernance ? Si vos dirigeants ont atteint leur date de péremption, si l’on voit toujours les mêmes vieilles têtes, les gens partiront dès qu’ils voudront être plus présents dans la prise de décisions. Si des personnes brillantes quittent votre communauté, vous devriez peut-être mettre au point une façon de les garder parmi vous.

Dans une communauté accueillante de niveau 3 :

  • les avis critiques sont récompensés et les questions des nouveaux sur les points flous sont encouragées ;
  • les responsables et/ou les personnes qui font la maintenance tournent selon un planning défini ;
  • les arrêts et les vacances sont encouragés, ainsi les nouveaux « mainteneurs » ont plus de chance d’acquérir de nouvelles compétences ;
  • Les membres de la communauté rédigent des tutoriels sur la revue des correctifs (patch), la gestion des diffusions, et l’aspect social du développement de logiciel ;
  • des mentors pour les nouveaux intervenants lors des conférences sont épaulés par des mentors ;
  • le code de conduite encourage à éviter le burn-out et aussi à respecter les personnes qui quittent le projet.

Niveau 4 : empathie et vigilance

Une fois que vous avez réglé le problème des départs et que des moyens sont mis en œuvre pour éviter le burn-out des développeurs, il est temps de s’attaquer au problème qu’évite la majorité des geeks : la question des relations sociales. Vos leaders ont des opinions différentes, comme cela devrait être le cas dans toutes les bonnes communautés ! Néanmoins, il faut prendre des garanties pour éviter que celui qui parle le plus fort finisse par gagner par épuisement des autres, et pour que les personnes moins connues ou minoritaires puissent être entendues.

Dans une communauté accueillante de niveau 4 :

  • les développeurs, les chasseurs de bugs et tous les autres contributeurs sont sur un pied d’égalité ;
  • on effectue des mises au point sur des questions non techniques, telles que des discussions sur des problèmes culturels ou politiques avec un suivi clair de la part des responsables ;
  • la documentation est en constante amélioration ;
  • les dirigeants montrent leur capacité à reconnaître leurs erreurs et à modifier leur comportement face aux critiques ;
  • les community managers font des rappels au code de conduite quand c’est nécessaire ;
  • le code de conduite insiste sur la nécessité d’écouter les différents points de vue ;

Niveau 5 : diversité

Une fois que vous avez mené tous ces changements culturels, vous pouvez chercher activement encore plus de personnes originales et avoir l’espoir de les garder parmi vous.

Dans une communauté accueillante de niveau 5 :

  • le comité décisionnaire (quel que soit son nom) comprend au moins 30 % de nouveaux, et il y a une rotation des habitués ;
  • la recherche de nouveaux leaders se fait en dehors des réseaux et des têtes connues ;
  • la communauté participe à des programmes promouvant la diversité ;
  • la diversité n’est pas seulement une action de relations publiques, les développeurs cherchent réellement de nouvelles perspectives et s’efforcent de reconnaître leurs propres privilèges ;
  • lors des conférences, le genre de l’intervenant ne doit pas être un problème ;
  • lors des conférences, on peut s’occuper des enfants, savoir si les plats sont végétariens ou pas, et lire un règlement intérieur clair ;
  • la politique concernant l’alcool encourage les participants à prendre du bon temps plutôt qu’à se saouler ;
  • le code de conduite protège explicitement la diversité parmi les développeurs et présente l’éventail de leurs droits ;
  • le comité chargé de faire s’appliquer le code de conduite inclut des représentants de la diversité issus de la communauté.

Ce qui m’agace le plus c’est quand une communauté saute des étapes. « Hé, nous avons un code de conduite et on accueille les enfants mais les harceleurs notoires sont invités à nos conférences ! », « Nous voulons participer à un programme pour la diversité, mais nous n’avons aucun mentor ni aucune idée de ce qu’un contributeur pourrait faire sur le long terme ! ».

— Eh bien, faites d’abord votre révolution culturelle, s’il vous plaît !

Sarah-Sharp
Photo Sarah Sharp  © pcofficina.org licence CC BY-NC-ND

—-

* DISCON (DEFCON Insult Scale for DIScussion – Échelle d’insulte DEFCON pour les discussions) est une échelle fictive qui s’inspire de DEFCON (le niveau d’alerte militaire des forces armées des États-Unis).

je lis des livres et mange des nouilles.

2 Réponses

  1. Merci Framasoft de faire bouger les choses dans le bon sens sur tous les fronts! 🙂

  2. Ca me parait correspondre assez à WordPress, Eclipse ou Ubuntu, mais faudrait valider avec des gens de l’intérieur ayant des responsabilités.

    En tout cas, certains point sont compliqués à mettre en oeuvre. Notamment le renouvellement des leaders car ils aiment bien garder leur pouvoir et leurs privilèges. Mais surtout, l’égalité entre les contributeurs, y compris les non codeurs, est globalement un point à améliorer dans les communautés Open Source: bien souvent si tu codes pas, ton avis ne compte pas (et je sais de quoi je parle).

Laissez un commentaire