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.
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.
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.
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.
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 :
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.
La première étape consiste à mettre en place une organisation GitHub et à créer deux référentiels :
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 :
À 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.
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.
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 :
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.
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.
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.
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 :
README.md
ou .json
sur GitHub ; tout le monde peut modifier, aucun CMS ou compte, etc. requisevents
)
Toutes ces fonctionnalités ont été possibles grâce à l' API GraphQL et en analysant les fichiers Markdown avec l'analyseur de corps.
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é :
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 :
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.