paint-brush
GitHub et l'art de créer des communautés ouvertesby@patrickheneise
184

GitHub et l'art de créer des communautés ouvertes

Patrick Heneise11m2023/12/20
Read on Terminal Reader

Dans cet article, je partage mon expérience et mes idées sur la façon de créer des communautés ouvertes. J'ai travaillé sur ce concept et ces outils pour rassembler les éléments en vue de l'automatisation de la communauté et j'espère que cela pourra vous aider, vous et votre communauté, à rendre les choses plus faciles.
featured image - GitHub et l'art de créer des communautés ouvertes
Patrick Heneise HackerNoon profile picture
0-item
1-item
2-item

Les communautés sont difficiles. Ils sont difficiles à construire, difficiles à entretenir et difficiles à développer. Mais bâtir des communautés a été l’une des choses les plus gratifiantes de ma carrière, car j’ai rencontré tellement de gens extraordinaires et j’ai été obligé d’apprendre et de faire des choses hors de ma zone de confort.


Je me souviens qu'il y a plus de 10 ans, j'ai assisté à ma première petite conférence technologique : CouchConf à Berlin. Heureusement, il y avait un BerlinJS Meetup à peu près au même moment et j'ai été époustouflé par la communauté et les gens. Ils ont mis en place un référentiel GitHub pour le site Web et les discussions sont soumises sous forme de problèmes GitHub. J'ai été étonné par la simplicité et la transparence du processus, j'ai donc créé le repo et fondé BarcelonaJS quelques semaines plus tard. Ce fut le début de mon propre parcours d’organisateur.


Une petite anecdote d'une expérience régulière et très frustrante : vous avez passé des heures à préparer, communiquer, trouver et inviter des conférenciers, trouver et fixer une date et un lieu, discuter avec des sponsors pour de la nourriture et des boissons, le tout pour organiser un grand événement. Et le moment venu, vous êtes assis seul ou avec une fraction des personnes que vous pensiez venir, car Meetup dit "150 personnes ont répondu OUI". Et dans une rare occasion, c'était simplement de la malchance avec la météo, mais le plus souvent, lorsque je parlais aux gens par la suite, j'entendais ceci :


C'est incroyable, j'aurais aimé y être, mais je ne savais pas !


Cette phrase m'a motivé à commencer à explorer GitHub en tant qu'outil communautaire, car GitHub est l'une des plateformes d'automatisation les plus étonnantes et c'est ce que vous devez faire en tant qu'organisateur : automatiser tout pour publier l'événement sur Eventbrite, Meetup, Twitter, Facebook, Telegram Groups, WhatsApp, Email, Calendrier, etc. etc. etc. et faites-le 2 semaines avant, 1 semaine avant, 3 jours avant, 1 jour avant, 1 heure avant l'événement pour que personne ne puisse le dire après : "Je ne savais pas". Parce qu'en fin de compte, vous ne faites pas cela pour vous-même mais pour la communauté.


Au cours de mes voyages, je suis tombé sur des communautés Node.js et JavaScript sur Meetup avec des milliers de membres, mais pas un seul événement à venir ou récent. Cela peut arriver pour de nombreuses raisons, mais c'est souvent parce que les organisateurs n'ont pas le temps ou sont passés à autre chose, et il est difficile de trouver un successeur pour faire fonctionner les choses. Meetup et autres plateformes sont idéales pour la découverte de communautés et d'événements, mais elles rendent difficile pour les membres de contacter la communauté au cas où un organisateur ne serait plus actif et de reprendre/relancer la communauté.


En tant que développeur, je passe beaucoup de temps sur GitHub et je connais les outils et les flux de travail. J'ai donc commencé à explorer comment utiliser GitHub comme plate-forme communautaire.

Avantages de l'utilisation de GitHub pour le renforcement de la communauté

Open Source et communauté ouverte

Le premier et le plus évident avantage est que les référentiels publics sur GitHub sont Open Source. Cela signifie que tout le contenu, les problèmes et les discussions sont publics et peuvent être copiés, copiés et réutilisés par n'importe qui. C'est formidable pour les communautés car cela signifie que si la communauté est abandonnée, n'importe qui peut la débourser et continuer le travail. Cela signifie également que si vous souhaitez créer une nouvelle communauté, vous pouvez en créer une existante et l'adapter à vos besoins.


GitHub intègre une gestion des utilisateurs/équipes/organisations, vous n'avez donc pas besoin de créer quoi que ce soit vous-même. Il est facile d'inviter quelqu'un dans l'organisation ou d'ajouter des équipes avec différentes autorisations de l'organisation.


La plupart d'entre nous savent utiliser GitHub et visitent le site quotidiennement. Il n'est donc pas nécessaire de mettre en favoris des sites supplémentaires pour l'administration de bases de données, la gestion de contenu ou d'autres outils. Avec GitHub Actions, nous pouvons exécuter des tâches automatisées selon un calendrier ou à la demande, et avec GitHub Pages, nous pouvons héberger gratuitement notre site Web communautaire.

Construire en public et en transparence

Pour moi, l’un des avantages les plus importants de la création d’une communauté sur GitHub est une transparence totale et une communication ouverte. Tout[1] est public, vous n'avez donc pas à vous soucier de savoir qui a accès à quoi. Cela signifie que n'importe qui peut contribuer à la communauté et que tout le monde peut voir ce qui se passe. C’est idéal pour instaurer la confiance et bâtir une communauté inclusive et accueillante pour tout le monde.


Mon objectif avec des communautés comme BarcelonaJS, CDC, etc. était/est de créer des espaces libres et ouverts permettant aux développeurs de partager et de se connecter. Et c'est dans la notion de « gratuité » que la transparence entre en jeu. Dans le passé, j'ai toujours évité de toucher aux contributions financières. Si une entreprise souhaitait sponsoriser, elle pouvait commander de la nourriture ou des boissons directement sur place, mais je ne faciliterais pas. Grâce à l' Open Collective , cela est devenu beaucoup plus facile et nous sommes désormais en mesure d'accepter des contributions financières et de les rendre transparentes pour la communauté. Ceux-ci sont utilisés par exemple pour payer le(s) domaine(s), pour obtenir de la nourriture et des boissons, lancer des campagnes publicitaires, etc.


[1] bien sûr, vous pouvez également créer un dépôt privé pour les discussions des organisateurs internes, etc.

Inconvénients et mises en garde

GitHub n'est pas une plateforme communautaire/événementielle comme Meetup, il y a donc quelques mises en garde. Je me suis habitué à traiter les problèmes comme des « événements » ou des « propositions de discussion » et à utiliser des formulaires de problèmes GitHub pour structurer les soumissions. Mais ce n'est pas idéal et il faut du temps aux nouveaux arrivants pour comprendre « Créer un problème pour soumettre une présentation ». Il n'y a pas de « fonctionnalités de confort » pour choisir une date, un emplacement sur une carte, etc. et déclencher une simple notification par e-mail à des centaines de personnes.

La communauté ouverte (développeurs)

L’ensemble de ce concept s’adresse principalement aux développeurs et aux ingénieurs, car il évolue autour de GitHub et IssueOps. Pour donner une idée de mon expérience précédente, voici quelques communautés et conférences que j'ai contribué à construire :


  • BarceloneJS , 2012 - 2018
  • Hackers et fondateurs Barcelone, 2012 - 2015
  • Groupe Meetup Node.js à Barcelone, 2012 - 2018
  • Meetup Couchbase Barcelone, 2012 - 2015
  • NodeConf Barcelone, 2015, 2016, 2017
  • MediterraneaJS, 2015
  • ChypreJS 2018 - 2021
  • Communauté de développeurs de Chypre 2020 - présent


Lors de leur création, j'ai continuellement travaillé sur un ensemble d'outils, de flux de travail et d'automatisation pour faciliter la vie des organisateurs, car c'est un travail très difficile et souvent ingrat. Voici donc mon concept de communauté ouverte sur la façon dont je construis une communauté publique sur GitHub.

Étiquettes et structure

La première étape consiste à mettre en place une organisation GitHub et à créer deux référentiels :

  1. événements
  2. pourparlers


Les noms sont évidents : dans le référentiel d'événements se trouvent des modèles pour créer de nouveaux événements , et dans le référentiel de discussions se trouvent des modèles pour soumettre des propositions de discussion . Les discussions peuvent être liées à des événements pour établir un agenda et, si vous parvenez à obtenir l'engagement de la communauté (rappelez-vous : c'est difficile !), des commentaires et des réactions tels que 👍 ou ❤️ peuvent être utilisés pour voter sur les discussions.


Vous pouvez également utiliser un projet GitHub pour gérer le cycle de vie de l'événement à travers les phases de proposition, de planification et d'annonce :

Vue du projet GitHub


À Chypre, nous avons ajouté des labels pour les différentes régions de l'île, mais il faut surtout un label « Approuvé ». Tous les nouveaux tickets sont créés avec le label « Événement », mais seule une personne disposant de l'autorisation de « triage » (équipe organisatrice) peut « approuver » l'événement. Ceci est important pour éviter le spam et pour garantir la pertinence de l'événement.

Étiquettes d’événements GitHub


Maintenant qu'il y a une organisation, des dépôts avec des problèmes et une structure en place, il est temps d'automatiser.

Événements Git

GitEvents / GitEvents sur GitHub remonte à (2014) et a commencé avec le nom gitup en tant que « week-end de hack » de collaboration entre le London Node User Group (LNUG) et le Barccelona Node.js Group. À l'époque, les actions GitHub n'existaient pas et nous avons essayé d'utiliser des Webhooks pour créer des données structurées pour les sites Web hébergés par GitHub, basés sur les données Meetup.com. La configuration était lourde et le projet a été abandonné pendant un certain temps.


Aujourd'hui, GitEvents est un simple ensemble d'actions GitHub permettant d'automatiser les workflows de problèmes. "Git Ops" pour les rencontres et les événements. Tout ce dont vous avez besoin est une organisation GitHub et une application GitHub. Certaines des fonctionnalités sont :


  • Organisation inclusive : toute interaction avec les référentiels, problèmes ou discussions GitHub déclenche un workflow pour inviter l'utilisateur dans l'organisation GitHub et l'ajoute à l'équipe "Membres de la communauté". Les autorisations sont les mêmes que pour le public, mais un petit « hack de croissance et d'engagement » est que vous pouvez @-mentionner tous les membres de la communauté dans les problèmes. C'est idéal pour les annonces, mais il ne faut pas en abuser, sinon vous perdez rapidement des membres.
  • Modèles de problèmes : j'ai élaboré un ensemble de modèles simples pour les événements, les discussions, les réponses au code de conduite, etc. afin de démarrer rapidement avec GitEvents.
  • Broadcast : sont des workflows GitHub réutilisables pour automatiser le marketing et les tâches courantes telles que l'envoi d'e-mails/tweet/blueskying aux membres, la création/mise à jour d'événements sur Discord, EventBrite, Meetup, etc.
  • ICS : est une action GitHub permettant de générer des fichiers iCal pour les événements. iCal est une norme pour les événements de calendrier. Les gens peuvent simplement l'ajouter sous forme d'abonnement à leur calendrier pour se tenir au courant des événements communautaires. Nous avons créé une redirection vers le fichier github, afin que les gens puissent s'abonner au calendrier avec un simple lien : https://calendar.cdc.cy .


Tout est "plug and play", vous pouvez donc choisir les actions que vous aimez et il est relativement facile de les composer dans un flux de travail. Pour des exemples, consultez les workflows de la communauté des développeurs de Chypre .


Si vous souhaitez démarrer avec GitEvents et avez besoin d'aide, veuillez contacter notre serveur Discord. GitEvents est un travail en cours et il y a toujours beaucoup à faire , en particulier avec les intégrations à d'autres plates-formes, etc. Si vous souhaitez aider, veuillez entrer en contact.

Formulaires de problème GitHub

Les formulaires de problèmes sont encore une fonctionnalité relativement peu connue sur GitHub. Au lieu d'un modèle Markdown classique, un fichier YAML peut être fourni avec une configuration de formulaire.

Formulaire de problème GitHub


C'est plutôt cool d'obtenir une entrée structurée, mais une fois enregistrées en tant que "Problème", les données sont sémantiquement inutiles car il ne s'agit que de Markdown. J'ai expérimenté avec les jalons, les en-têtes Markdown, les étiquettes, etc. pour ajouter des informations sémantiques telles que des dates, des lieux, etc. à un problème, mais rien n'a bien fonctionné. J'ai donc commencé à créer GitHub Issue Forms Body Parser . Cela permet d'analyser un problème créé via un formulaire pour extraire des dates, des liens, des images, des listes, etc. et les convertir en données JSON structurées. Cela peut être directement transmis à d'autres plateformes comme Discord, EventBrite, Meetup, etc. ou utilisé dans des mailings, des tweets, etc.


L' analyseur de corps de formulaires de problème est également disponible sur npm en tant que bibliothèque pour analyser n'importe quel texte Markdown. Ce n'est que récemment que j'ai réalisé que des fichiers README.md entiers pouvaient être analysés pour structurer les données d'un site Web :


 query ($organization: String!, $repository: String!) { repository(owner: $organization, name: $repository) { id name object(expression: "main:README.md") { ... on Blob { text } } } }


Il s'agit de la requête permettant de récupérer le contenu d'un fichier de la branche main d'un référentiel, et vous pouvez le transmettre à "l'analyseur de corps" :

const structuredData = await bodyParser(readmeFile()?.repository.object.text)


Au lieu de conserver une autre copie de la description de votre communauté, vous pouvez désormais récupérer la section About du fichier README.md et l'utiliser sur votre site Web.

API GraphQL

Avec le dernier site Web https://cdc.cy , je voulais explorer et repousser les limites de ce qui est possible avec les problèmes, les fichiers README.md et les données JSON structurées et je suis assez satisfait du résultat :


  • la plupart du contenu du site Web est extrait des fichiers README.md ou .json sur GitHub ; tout le monde peut modifier, aucun CMS ou compte, etc. requis
  • les événements à venir et passés sont basés sur les problèmes GitHub (problèmes approuvés et étiquetés par événement sur le dépôt events )
  • les organisateurs sont récupérés auprès des membres de l'équipe GitHub
  • Les événements peuvent être annotés/améliorés avec des données de localisation appropriées à partir d'un fichier « emplacements communs »
  • Les profils d'intervenants sont entièrement basés sur les profils utilisateur GitHub, nous pouvons récupérer des avatars, une biographie (lisez-moi), un emplacement, etc. et créer de jolies pages de profil d'intervenant.
  • Nous pouvons afficher certaines statistiques telles que « nombre de membres de l'organisation », « nombre d'événements passés/à venir », etc.


Toutes ces fonctionnalités ont été possibles grâce à l' API GraphQL et en analysant les fichiers Markdown avec l'analyseur de corps.

Résumé et perspectives

Je travaille sur ce concept depuis un moment et il change encore de forme de temps en temps. Mais les idées de base que j'ai adoptées de BerlinJS n'ont pas changé :


  • Communauté ouverte : tout est public et transparent, et tout le monde est le bienvenu (à condition de respecter le code de conduite)
  • Les événements et les discussions/propositions sont des numéros dans un référentiel
  • Les étiquettes aident à la structure et à l’automatisation


Construire tout cela a pris beaucoup de temps et d'énergie et il manque encore beaucoup de choses pour lesquelles je n'ai pas le temps :

  • bonne intégration du courrier électronique avec les horaires, les rappels, etc.
  • finaliser l'intégration d'EventBrite
  • ajouter l'intégration Meetup
  • ajouter l'intégration WhatsApp/Telegram/Slack
  • améliorer la gestion des problèmes et les commentaires automatiques (c'est-à-dire rappel du code de conduite, rappel de suivi, etc.)


Si vous pensez que cela peut vous aider, vous et votre communauté, et que vous souhaitez participer à la reconstitution du puzzle, veuillez nous contacter sur le serveur Discord de gitevents , sur les discussions GitHub ou directement sur l'un des problèmes GitHub .


Si vous êtes à Chypre ou à Barcelone , rejoignez et soutenez les groupes de développeurs locaux.

Réflexions, trucs et astuces des organisateurs aléatoires tirés de leur expérience personnelle

  • Lieux : choisir un bureau d’entreprise comme lieu est facile, mais présente de nombreux inconvénients. Il est facile de manipuler les gens une fois qu'on les a au bureau (regardez notre endroit sympa, nous avons même un bar à cocktails !). N'oubliez pas que l'entreprise a des motivations différentes des vôtres (recrutement, marketing, etc.). Parfois, il peut même y avoir des conflits, au point que les gens ne sont pas autorisés à se rendre au bureau des concurrents. Si possible, je préfère les espaces de coworking et événementiels « neutres » et grâce à Open Collective vous pouvez obtenir des parrainages pour payer le lieu avec des règles (recrutement/marketing/etc) équitables pour tout le monde.
  • Rappels : nous sommes tous occupés et il est facile d'oublier des choses. Tout le monde n'est pas aussi engagé, motivé et excité que vous par l'événement, donc des rappels réguliers maintiennent les gens engagés et aident à développer une habitude. Trouvez une bonne cadence pour les rappels, n’en faites pas trop et n’envoyez pas de spam aux gens. Différents médias fonctionnent pour différentes personnes, j'essaie donc d'en couvrir le plus grand nombre possible.
  • Rareté "J'ai remarqué qu'annoncer l'événement juste une semaine avant qu'il ait lieu et avoir un nombre limité de sièges fonctionne mieux que de le publier un mois à l'avance avec plus de 100 places" – Dmitry Zaets, BarcelonaJs
  • Avantages : "Les cadeaux sont amusants, et offrir des billets pour des conférences et d'autres choses peut être un avantage appréciable pour y assister" – Dmitry Zaets, BarcelonaJs
  • Cohérence : "Établissez un calendrier réaliste dès le départ. Qu'il s'agisse d'une rencontre mensuelle ou d'une conférence trimestrielle, la cohérence est la clé. Créez une feuille de route, répartissez les responsabilités et respectez le plan. Cela non seulement maintient votre public engagé, mais aide également à construire une communauté fiable. – Federico Rampazzo, CDC.cy
  • Trouver des conférenciers : "N'ayez pas peur d'approcher des experts qui pourraient être disposés à partager leurs idées. Beaucoup de vos membres auront probablement des histoires intéressantes qui méritent d'être partagées ! Cela peut être une expérience enrichissante pour eux autant que pour la communauté. Prendre des photos, des vidéos et des enregistrements audio des événements est précieux et aide les orateurs dans leur carrière d'orateur, tout en augmentant la portée de l'événement. – Federico Rampazzo, CDC.cy