9 responsabilités sous-estimées d’un gestionnaire de communauté open source

Les communautés open source ne sont pas le fruit du hasard. Ils demandent du travail. Parfois, l’intérêt technique pour un projet open source suffit à attirer un groupe de personnes à s’impliquer. Cependant, après un certain temps, les choses vont devenir trop importantes pour ceux qui ont un penchant particulier (documentation, codage, tests) pour gérer les interactions entre les différents participants, modérer les communications maladroites (ou carrément agressives), aider à encourager les nouveaux membres à contribuer , augmenter la visibilité du projet dans de nouveaux domaines ou secteurs de marché, et tous les autres éléments qui contribuent au maintien d’un projet en bonne santé.

Entrez le gestionnaire de communauté. Le gestionnaire de communauté typique est dans cette position inconfortable d’avoir beaucoup de responsabilités mais aucune autorité directe. Les projets open source étant ce qu’ils sont, peu d’entre eux ont des « agents » habilités et même lorsqu’il existe des structures de gouvernance, ils ont tendance à fonctionner avec le consentement des personnes impliquées – par une autorité négociée plutôt que directe. Cela dit, au moment où un gestionnaire de communauté est nommé, il est probable qu’au moins une entité commerciale soit suffisamment impliquée dans le projet pour financer ou financer en partie le poste de gestionnaire de communauté. Cela signifie que le gestionnaire de communauté bénéficiera, espérons-le, du soutien d’au moins un ensemble de contributeurs, mais devra toujours établir un consensus dans le reste de la communauté. Il peut y avoir des moments difficiles où le gestionnaire de communauté devra décider si sa loyauté va à son employeur ou à la communauté. Un employeur avisé devrait définir des attentes sur la façon de gérer de telles situations avant qu’elles ne surviennent !

Que doit faire le community manager alors ? La réponse à cette question dépendra d’un certain nombre de problèmes, et il y aura probablement un équilibre entre ces tâches, mais voici une liste de celles qui me viennent à l’esprit. Comme toujours, je suis ouvert aux commentaires et suggestions sur la façon d’améliorer ou d’étendre cette liste.

• Marketing/diffusion – il s’agit d’augmenter la visibilité du projet, soit dans des domaines où il est déjà connu, soit dans de nouveaux marchés/secteurs. Il existe de nombreuses sous-tâches telles que l’image de marque, la commande de swag (et la distribution !), l’analyste et les relations avec la presse.
• Gestion d’événements – mise en place de meetups, hackathons, stands lors d’événements plus importants ou, pour de très gros projets, organisation de conférences.
• Croissance de la communauté – repérer les domaines où le projet pourrait avoir besoin de plus d’aide (documents, tests, sensibilisation, codage, représentation diversifiée et inclusive, etc.), et trouver des moyens de recruter des contributeurs pour aider à améliorer le projet.
• Lubrification communautaire – il s’agit de trouver des moyens de garder les membres de la communauté à se parler, de célébrer les succès, de pleurer les pertes et, en général, de garder les conversations au moins civiles et au mieux amicales avec enthousiasme.
• Stratégie de projet – il y a des moments dans un projet où de nouveaux pâturages peuvent se présenter (une nouvelle fonctionnalité peut rendre le projet passionnant pour la communauté des soins de santé ou de l’astronomie universitaire, par exemple), et le gestionnaire de communauté doit reconnaître ces opportunités, les présenter au communauté et aider la communauté à s’orienter.
• Gestion des produits – en conjonction avec la stratégie du projet, des situations sont susceptibles de se produire lorsqu’un ensemble de caractéristiques ou de fonctionnalités sont présentés à la communauté qui nécessitent des décisions concernant leur priorité ou la capacité de la communauté à les ressourcer. Ceux-ci peuvent même créer des tensions entre diverses parties de la communauté, y compris les intérêts commerciaux impliqués. Le community manager doit aider la communauté à raisonner sur la manière de faire des choix et peut même être appelé à diriger le processus de prise de décision.
• Gestion des partenaires – à mesure qu’un projet se développe, des partenaires (projets open source, institutions académiques, associations caritatives, consortiums industriels, ministères ou organisations commerciales) peuvent souhaiter s’associer au projet. Gérer les attentes et comprendre les avantages (ou les dangers) et la valeur relative peuvent être complexes et prendre du temps, et le gestionnaire de communauté sera probablement la première personne impliquée.
• Gestion documentaire – bien que la documentation ne soit qu’une partie d’un projet, elle peut souvent être négligée par les principaux contributeurs au code. Il s’agit toutefois d’une ressource vitale lorsque l’on considère bon nombre des tâches associées aux points ci-dessus. Gérer la stratégie, travailler avec des partenaires, créer des communiqués de presse : tout cela nécessite une bonne documentation. Bien qu’il soit peu probable que le gestionnaire de communauté ait besoin de l’écrire (enfin, j’espère que non tous de celui-ci !), en s’assurant que c’est là qu’il est susceptible d’être leur responsabilité.
• Habilitation des développeurs – il s’agit de fournir des ressources (y compris, mais sans s’y limiter, de la documentation) pour aider les développeurs (en particulier ceux qui découvrent le projet) à s’impliquer. Il est souvent considéré comme une bonne idée de séparer cet ensemble de tâches, plutôt que de s’attendre à un rôle distinct de celui d’un gestionnaire de communauté, en partie parce que cela peut nécessiter une concentration technique plus approfondie que celle requise pour de nombreuses autres responsabilités associées à la rôle. C’est probablement raisonnable, mais le gestionnaire de communauté voudra probablement s’assurer que l’activation des développeurs est bien gérée, car, sans nouveaux développeurs, presque tous les projets finiront par se calcifier et mourir.

Personne (enfin, presque personne) ne sera un expert dans tous ces ensembles de tâches, et de nombreux projets n’auront pas besoin de toutes en même temps. Deux des attributs d’un gestionnaire de communauté bien établi sont la conscience des lacunes de son expertise et un réseau de contacts auquel il peut faire appel pour obtenir des conseils ou des services pour combler ces lacunes.

Je ne suis pas – et ne pourrais jamais être – un gestionnaire de communauté. Je n’ai pas les compétences (ou la patience), et l’une des joies d’acquérir de l’expérience et de l’expertise dans le monde est de réaliser quand d’autres faire avoir des compétences qui vous manquent et être capable de reconnaître et de célébrer ce qu’ils peuvent apporter à votre monde que vous ne pouvez pas. Alors merci, community managers.

Cet article a été initialement publié le Alice, Eve et Bob et est réimprimé avec l’autorisation de l’auteur.