Article original : Building Online Communities: Node-Pixel.
Par Gitter
_Andrew Fisher travaille sur un projet fusionnant matériel et logiciel pour créer des effets lumineux magnifiques. Il nous a parlé de sa manière de favoriser et de gérer la communauté open source autour de son projet. Découvrez ce qu'il dit et consultez le canal Gitter de Node-Pixel._
Parlez-nous un peu de vous et de la communauté Node-Pixel. Qu'est-ce que Node-Pixel ? Comment tout a commencé ?
Je suis développeur web depuis 20 ans et maintenant CTO de LUXE City Guides. J'ai toujours été impliqué dans la communauté open source sous diverses formes et, au cours des dernières années, j'ai été profondément impliqué dans la communauté JavaScript Robotics (nodebots).
Node-Pixel est né de cela, avec le projet fusionnant très spécifiquement matériel et logiciel (JavaScript) pour créer de magnifiques effets lumineux. Cela a commencé parce qu'historiquement, il n'y avait pas de moyen facile de le faire dans le monde du matériel JS et j'adore les jolies lumières, alors j'ai décidé de construire quelque chose qui le ferait.
La communauté est définitivement un sous-ensemble des communautés Johnny-Five et NodeBots, avec ceux qui s'intéressent spécifiquement à l'éclairage matériel en faisant partie (d'autres groupes sont plus intéressés par la robotique traditionnelle ou la domotique, etc.). Le projet a vu des commits de développeurs incroyablement talentueux du monde entier qui ont aidé à réaliser l'objectif d'une manière simple de contrôler l'éclairage matériel à partir de JavaScript.
Quels sont les objectifs communs que vous avez en tant que communauté ?
En gros, comme expliqué ci-dessus, vraiment le désir de voir les gens utiliser le matériel avec JavaScript et en particulier pouvoir travailler avec du matériel très sophistiqué en utilisant une manière simple de le faire.
Quels sont les problèmes liés au projet Node Pixel qui vous enthousiasment le plus ces jours-ci ?
Définiment l'intégration plus large dans Interchange, un projet auquel je participe également. Interchange résout pour les firmwares matériels ce que pip et npm résolvent pour les modules python et javascript — c'est-à-dire, la gestion de paquets pour des cibles spécifiques. Le projet Node Pixel a illustré le besoin de cela dans le monde du matériel JS et a conduit à la création d'Interchange, donc le rendre pleinement compatible avec Interchange est un grand objectif.
Au-delà de cela, la prochaine grande poussée consiste à rendre la bibliothèque plus capable de choses comme l'animation et autres, pour créer des effets lumineux vraiment sophistiqués et les déclencher tous à partir de NodeJS ou potentiellement directement depuis le navigateur.
Quels sont les facteurs les plus importants que vous avez pris en compte lors de la création et de la maintenance de la communauté ? Quels facteurs contribuent au succès de votre communauté ?
Les plus grandes choses, je pense, ont été la transparence — nous utilisons Gitter et les problèmes GitHub comme une grande partie de cela pour favoriser la collaboration entre les personnes qui sont géographiquement séparées. Avoir des logs de nos discussions, etc., facilite le retour vers la communauté pour expliquer la raison derrière quelque chose, surtout s'ils sont utilisateurs du projet mais ne contribuent peut-être pas à celui-ci.
En relation avec cela, nous respectons un Code de Conduite pour la contribution au projet et depuis le début, nous avons toujours cherché à favoriser une communauté ouverte, digne de confiance, sûre et responsable. Je pense que lorsque les gens établissent cela comme simplement « la manière dont les choses sont », cela aide les gens à adopter cet ensemble de normes lorsqu'ils s'engagent. Node Pixel a été bon à cet égard mais doit vraiment beaucoup au travail plus large effectué dans le monde du matériel JS par Johnny-Five et JavaScript en général pour assurer des lieux sûrs.
Quels sont les principaux défis que vous rencontrez lors de la gestion de la communauté ?
Les fuseaux horaires !!!!
Je suis en Australie et la plupart de mes collaborateurs sont aux États-Unis et dans l'UE, donc trouver des chevauchements peut être vraiment difficile lorsque nous travaillons sur la construction de fonctionnalités, etc. Il faudrait réduire la taille des océans Pacifique ou Indien de moitié ;)
Quels sont les principaux problèmes discutés dans le canal du projet Node Pixel sur Gitter ?
Une grande partie des discussions quotidiennes tourne autour du support pour les personnes utilisant le projet. Nous sommes très vocaux sur notre utilisation de Gitter comme canal de support principal, donc nous encourageons les gens à passer et à poser des questions. Cela aide les gens à se lancer rapidement avec le projet.
Outre cela, alors que nous construisons des fonctionnalités, il y a beaucoup de discussions aller-retour sur les approches, des notes sur les revues de code, etc. GitHub aide avec cela, cependant nous avons tendance à utiliser GH comme la deuxième partie de ce bavardage plus libre tandis que nous arrivons à une approche, puis nous utilisons GH pour documenter les problèmes et les étapes vers la résolution.
Sur la base de votre expérience, pensez-vous que les communautés open source ont changé et évolué au cours des dernières années ? Si oui, comment ?
Définiment. Il y a du bon et du mauvais dans cela. D'une part, l'open source a plus ou moins « gagné » une grande partie de la manière dont nous construisons des logiciels. En tant que développeurs, nous voulons pouvoir voir, valider et modifier le code que nous exécutons dans nos propres projets. À cet égard, je pense que le développement logiciel est devenu beaucoup plus ouvert pour tout le monde et, espérons-le, cela aide les futurs développeurs à apprendre et à ne pas répéter les erreurs du passé en raison du manque d'informations.
La mauvaise partie est qu'il peut y avoir beaucoup de consommation de la partie « gratuite » des logiciels libres et open source, où les consommateurs des projets s'attendent à ce que les correctifs soient effectués immédiatement ou qu'une nouvelle fonctionnalité soit ajoutée simplement parce qu'ils l'ont demandée. Pouvoir utiliser les outils pour engager les gens afin d'adoucir cette approche est inestimable, car vous pouvez souvent encourager quelqu'un à aider à contribuer et potentiellement construire la fonctionnalité qu'il souhaite voir dans le cadre du projet.
Dans l'ensemble, je pense que la communauté est plus une communauté maintenant et je crois que le bon l'emporte définitivement sur les aspects négatifs — mais nous devrions toujours chercher ce qui peut être fait pour aider tous les projets à avoir une meilleure expérience.
Quel conseil donneriez-vous à quelqu'un qui veut créer une communauté open source en ligne à partir de zéro ?
Parlez-vous à vous-même.
Cela semble bizarre, mais c'est souvent intimidant lorsque vous êtes la seule personne à travailler sur un projet. Vous avez une idée, vous mettez votre code en ligne et vous attendez que les gens le critiquent. Cela peut être très difficile car vous vous ouvrez à une critique potentielle.
L'une des façons dont je surmonte cela est de soulever des problèmes dans mon GitHub et de les assigner à moi-même. Je fais des revues de code de mon propre code et je prends des notes à ce sujet et je crée des tickets pour corriger le code. Je note également souvent les statuts actuels, etc., dans Gitter, même si je suspecte que personne ne le lira.
Cependant, le côté amusant de cette approche est qu'elle vous aide à être plus raffiné dans la manière dont vous parlez de votre projet aux autres plus tard, et vous construisez également un corpus de documentation, de raisonnement et de « vivacité » sur votre projet, ce qui facilite la contribution des autres — même s'ils pensent collaborer avec une personne folle qui se parle à elle-même (ce que nous faisons tous de toute façon).
Mon conseil est donc de vous parler à vous-même. Cela aide à articuler votre projet, vous rend abordable et une communauté doit commencer avec une personne, alors soyez la personne à partir de laquelle elle commence.
Merci !