paint-brush
GitHub y el arte de construir comunidades abiertaspor@patrickheneise
194 lecturas

GitHub y el arte de construir comunidades abiertas

por Patrick Heneise11m2023/12/20
Read on Terminal Reader

Demasiado Largo; Para Leer

En este artículo comparto mi experiencia e ideas sobre cómo construir comunidades abiertas. He estado trabajando en este concepto y herramientas para unir las cosas para la automatización comunitaria y espero que esto pueda ayudarlo a usted y a su comunidad a hacer las cosas más fáciles.
featured image - GitHub y el arte de construir comunidades abiertas
Patrick Heneise HackerNoon profile picture
0-item
1-item
2-item

Las comunidades son difíciles. Son difíciles de construir, de mantener y de cultivar. Pero construir comunidades ha sido una de las cosas más gratificantes de mi carrera, porque conocí a mucha gente increíble y me vi obligado a aprender y hacer cosas fuera de mi zona de confort.


Recuerdo que hace más de 10 años asistí a mi primera pequeña conferencia tecnológica: CouchConf en Berlín. Afortunadamente, hubo una reunión de BerlinJS casi al mismo tiempo y quedé impresionado por la comunidad y la gente. Tienen un repositorio de GitHub configurado para el sitio web y las charlas se envían como Problemas de GitHub. Me sorprendió la simplicidad y transparencia del proceso, así que bifurqué el repositorio y fundé BarcelonaJS unas semanas después. Este fue el comienzo del viaje de mis propios organizadores.


Una pequeña anécdota de una experiencia habitual y muy frustrante: pasó horas preparándose, comunicándose, buscando e invitando oradores, buscando y asegurando una fecha y un lugar, hablando con patrocinadores para obtener comida y bebidas, todo para organizar un gran evento. Y cuando llegue el momento, estarás sentado allí solo o con una fracción de las personas que pensabas que vendrían, porque Meetup dice "150 personas confirmaron su asistencia SÍ". Y en una rara ocasión fue simplemente mala suerte con el clima, pero más a menudo, cuando hablé con la gente después, escuché esto:


¡Esto es increíble, desearía haber estado allí, pero no lo sabía!


Esta frase fue la motivación para comenzar a explorar GitHub como una herramienta comunitaria porque GitHub es una de las plataformas de automatización más sorprendentes y eso es lo que debes hacer como organizador: automatizar todo para publicar el evento en Eventbrite. Meetup, Twitter, Facebook, Grupos de Telegram, WhatsApp, correo electrónico, calendario, etc., etc., etc. y hazlo 2 semanas antes, 1 semana antes, 3 días antes, 1 día antes, 1 hora antes del evento para que nadie pueda decir después. : "Yo no sabía sobre esto". Porque al final, no estás haciendo esto por ti mismo sino por la comunidad.


Durante mis viajes, me encontré con comunidades de Node.js y JavaScript en Meetup con miles de miembros, pero ni un solo evento próximo o reciente. Esto puede suceder por muchas razones, pero a menudo se debe a que los organizadores no tienen tiempo o han pasado a otras cosas, y es difícil encontrar un sucesor para que todo siga funcionando. Meetup y otras plataformas son excelentes para descubrir comunidades y eventos, pero dificultan que los miembros se comuniquen con la comunidad en caso de que un organizador ya no esté activo y se hagan cargo o revivan la comunidad.


Como desarrollador, paso mucho tiempo en GitHub y estoy familiarizado con las herramientas y los flujos de trabajo, así que comencé a explorar cómo usar GitHub como plataforma comunitaria.

Beneficios de usar GitHub para la creación de comunidades

Código abierto y comunidad abierta

El primer y más obvio beneficio es que los repositorios públicos en GitHub son de código abierto. Esto significa que todo el contenido, los problemas y las discusiones son públicos y cualquiera puede bifurcarlos, copiarlos y reutilizarlos. Esto es fantástico para las comunidades porque significa que si la comunidad se abandona, cualquiera puede bifurcarla y continuar el trabajo. También significa que si quieres iniciar una nueva comunidad, puedes bifurcar una existente y adaptarla a tus necesidades.


GitHub tiene incorporada la gestión de usuarios/equipos/organizaciones, por lo que no es necesario que crees nada tú mismo. Es fácil invitar a alguien a la organización o agregar equipos con diferentes permisos de la organización.


La mayoría de nosotros sabemos cómo usar GitHub y visitamos el sitio a diario, por lo que no es necesario marcar sitios adicionales para la administración de bases de datos, gestión de contenido u otras herramientas. Con GitHub Actions, podemos ejecutar tareas automatizadas según un cronograma o bajo demanda, y con GitHub Pages podemos alojar el sitio web de nuestra comunidad de forma gratuita.

Construyendo en Público y Transparencia

Para mí, uno de los beneficios más importantes de crear una comunidad en GitHub es la transparencia total y la comunicación abierta. Todo[1] es público, por lo que no hay necesidad de preocuparse por quién tiene acceso a qué. Esto significa que cualquiera puede contribuir a la comunidad y cualquiera puede ver lo que está pasando. Esto es excelente para generar confianza y construir una comunidad inclusiva y acogedora para todos.


Mi objetivo con comunidades como BarcelonaJS, CDC, etc. era/es crear espacios libres y abiertos para que los desarrolladores compartan y se conecten. Y "gratis" es donde entra en juego la transparencia. En el pasado, siempre mantuve mis manos alejadas de las contribuciones financieras. Si una empresa quisiera patrocinar, podría pedir comida o bebidas directamente en el lugar, pero yo no lo facilitaría. Gracias a Open Collective , esto se ha vuelto mucho más fácil y ahora podemos aceptar contribuciones financieras y hacerlas transparentes para la comunidad. Se utilizan, por ejemplo, para pagar los dominios, obtener comida y bebida, ejecutar campañas publicitarias, etc.


[1] por supuesto, también puede crear un repositorio privado para las discusiones de los organizadores internos, etc.

Inconvenientes y advertencias

GitHub no es una plataforma comunitaria/de eventos como Meetup, por lo que hay algunas advertencias. Me he acostumbrado a tratar los Issues como "Eventos" o "Propuestas de charla" y a los Formularios de Issues de GitHub para estructurar los envíos. Pero no es ideal y los recién llegados necesitan tiempo para entender "Crear un problema para enviar una charla". No hay "funciones cómodas" para elegir una fecha, ubicación en un mapa, etc. y enviar una simple notificación por correo electrónico a cientos de personas.

La comunidad abierta (de desarrolladores)

Todo este concepto se centra principalmente en desarrolladores e ingenieros, ya que evoluciona en torno a GitHub y IssueOps. Para dar una idea de mi experiencia anterior, aquí hay algunas comunidades y conferencias que he ayudado a construir:


  • BarcelonaJS , 2012 - 2018
  • Hackers y Fundadores Barcelona, 2012 - 2015
  • Grupo Meetup Node.js Barcelona, 2012 - 2018
  • Encuentro Couchbase Barcelona, 2012 - 2015
  • NodeConf Barcelona, 2015, 2016, 2017
  • MediterráneaJS, 2015
  • ChipreJS 2018 - 2021
  • Comunidad de desarrolladores de Chipre 2020 - presente


Mientras los construía, he trabajado continuamente en un conjunto de herramientas, flujos de trabajo y automatización para hacer la vida de los organizadores más fácil, porque es un trabajo muy duro y, a menudo, ingrato. Así que aquí está mi concepto de comunidad abierta sobre cómo construyo una comunidad pública en GitHub.

Etiquetas y estructura

El primer paso es configurar una organización GitHub y crear dos repositorios:

  1. eventos
  2. negociaciones


Los nombres son obvios: en el repositorio de eventos hay plantillas para crear nuevos eventos y en el repositorio de charlas hay plantillas para enviar propuestas de charlas . Las charlas se pueden vincular a eventos para crear una agenda y, si logras lograr la participación de la comunidad (recuerda: ¡es difícil!), comentarios y reacciones como 👍 o ❤️ se pueden usar para votar las charlas.


También puedes utilizar un Proyecto GitHub para gestionar el ciclo de vida del evento a través de las fases de propuesta, programación y anuncio:

Vista del proyecto GitHub


En Chipre, agregamos etiquetas para las diferentes regiones de la isla, pero lo más importante es que se necesita una etiqueta "Aprobado". Todos los problemas nuevos se crean con la etiqueta "Evento", pero sólo alguien con permiso de "clasificación" (equipo de organizadores) puede "aprobar" el evento. Esto es importante para evitar el spam y asegurarse de que el evento sea relevante.

Etiquetas de eventos de GitHub


Ahora que existe una organización, algunos repositorios con problemas y cierta estructura, es hora de automatizar.

Eventos Git

GitEvents / GitEvents en GitHub se remonta a 2014 y comenzó con el nombre gitup como una colaboración "fin de semana de hackeo" entre el London Node User Group (LNUG) y el Barccelona Node.js Group. En aquel entonces, GitHub Actions no existía e intentamos usar Webhooks para generar datos estructurados para sitios web alojados en GitHub basados en datos de Meetup.com. La instalación fue engorrosa y el proyecto fue abandonado por un tiempo.


Hoy en día, GitEvents es un conjunto simple de acciones de GitHub para automatizar los flujos de trabajo de problemas. "Git Ops" para reuniones y eventos. Todo lo que se necesita es una organización GitHub y una aplicación GitHub. Algunas de las características son:


  • Organización inclusiva : cualquier interacción con repositorios, problemas o discusiones de GitHub activa un flujo de trabajo para invitar al usuario a la organización de GitHub y lo agrega al equipo de "Miembros de la comunidad". Los permisos son los mismos que para el público, pero un pequeño "truco de crecimiento y participación" es que puedes @mencionar a todos los miembros de la comunidad en los problemas. Esto es excelente para anuncios, pero no se debe abusar de él, de lo contrario perderá miembros rápidamente.
  • Plantillas de problemas : preparé un conjunto de plantillas simples para eventos, charlas, respuestas al código de conducta, etc. para comenzar rápidamente con GitEvents.
  • Transmisión : son flujos de trabajo de GitHub reutilizables para automatizar el marketing y tareas comunes como enviar correos electrónicos, twittear o enviar mensajes a miembros, crear/actualizar eventos en Discord, EventBrite, Meetup, etc.
  • ICS : es una acción de GitHub para generar archivos iCal para eventos. iCal es un estándar para eventos de calendario. Las personas pueden simplemente agregar esto como una suscripción a su calendario para mantenerse actualizado con los eventos de la comunidad. Creamos una redirección al archivo github, para que las personas puedan suscribirse al calendario con un simple enlace: https://calendar.cdc.cy .


Todo es "plug and play", por lo que puedes elegir las acciones que te gusten y es relativamente fácil componerlas en un flujo de trabajo. Para ver ejemplos, consulte los flujos de trabajo de la comunidad de desarrolladores de Chipre .


Si desea comenzar con GitEvents y necesita ayuda, comuníquese con nuestro servidor Discord. GitEvents es un trabajo en progreso y siempre hay mucho que hacer, especialmente con integraciones a otras plataformas, etc. Si desea ayudar, por favor Ponerse en contacto.

Formularios de problemas de GitHub

Los formularios de problemas siguen siendo una característica relativamente poco conocida en GitHub. En lugar de plantillas de Markdown normales, se puede proporcionar un archivo YAML con una configuración de formulario.

Formulario de emisión de GitHub


Esto es genial para obtener información estructurada, pero una vez guardados como "Problema", los datos son semánticamente inútiles porque son solo Markdown. Experimenté con Hitos, encabezados de Markdown, Etiquetas, etc. para agregar información semántica como fechas, ubicaciones, etc. a un problema, pero nada funcionó bien. Entonces comencé a construir GitHub Issue Forms Body Parser . Esto ayuda a analizar un problema que se creó a través de un formulario para extraer fechas, enlaces, imágenes, listas, etc. y convertirlos en datos JSON estructurados. Esto puede transmitirse directamente a otras plataformas como Discord, EventBrite, Meetup, etc. o usarse en correos electrónicos, tweets, etc.


El analizador de cuerpo de formularios de problemas también está disponible en npm como biblioteca para analizar cualquier texto de Markdown. Recientemente me di cuenta de que se pueden analizar archivos README.md completos para estructurar datos de un sitio web:


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


Esta es la consulta para recuperar el contenido del archivo de la rama main de un repositorio, y puede pasarla al "analizador de cuerpo":

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


En lugar de conservar otra copia de la descripción de su comunidad, ahora puede obtener la sección About de del archivo README.md y utilizarla en su sitio web.

API GraphQL

Con el último sitio web https://cdc.cy quería explorar y ampliar los límites de lo que es posible con Issues, archivos README.md y datos JSON estructurados y estoy bastante satisfecho con el resultado:


  • la mayor parte del contenido del sitio web se obtiene de archivos README.md o .json en GitHub; todos pueden editar, no se requiere CMS ni cuenta, etc.
  • Los eventos próximos y pasados se basan en problemas de GitHub (problemas aprobados y etiquetados como eventos en el repositorio events )
  • los organizadores se obtienen de los miembros del equipo de GitHub
  • Los eventos se pueden anotar/mejorar con datos de ubicación adecuados desde un archivo de "ubicaciones comunes"
  • Los perfiles de los oradores se basan completamente en perfiles de usuario de GitHub, podemos obtener avatares, biografía (léame), ubicación, etc. y crear bonitas páginas de perfil de oradores.
  • Podemos mostrar algunas estadísticas como "número de miembros de la organización", "número de eventos pasados/próximos", etc.


Todas estas funciones fueron posibles a través de la API GraphQL y analizando los archivos Markdown con el analizador de cuerpo.

Resumen y perspectivas

He estado trabajando en este concepto por un tiempo y todavía está cambiando de forma de vez en cuando. Pero las ideas básicas que adopté de BerlinJS no han cambiado:


  • Comunidad Abierta : todo es público y transparente, y todos son bienvenidos (siempre que sigan el Código de Conducta)
  • Eventos y Charlas/Propuestas son ediciones en un repositorio
  • Las etiquetas ayudan con la estructura y la automatización


Construir todo esto ha requerido mucho tiempo y energía y todavía faltan muchas cosas para las que no tengo tiempo:

  • adecuada integración del correo electrónico con horarios, recordatorios, etc.
  • finalizar la integración de EventBrite
  • agregar integración de Meetup
  • agregar integración de WhatsApp/Telegram/Slack
  • mejorar el manejo de problemas y los comentarios automáticos (es decir, recordatorio del Código de conducta, recordatorio de seguimiento, etc.)


Si cree que esto puede ayudarlo a usted y a su comunidad y desea participar en la tarea de armar el rompecabezas, comuníquese con gitevents Discord Server , en GitHub Discussions o directamente en uno de los GitHub Issues .


Si estás en Chipre o Barcelona , únete y apoya a los grupos de desarrolladores locales.

Pensamientos, consejos y trucos de organizadores aleatorios de la experiencia personal

  • Lugares: elegir la oficina de una empresa como lugar de celebración es fácil, pero tiene muchos inconvenientes. Es fácil manipular a las personas una vez que las tienes en la oficina (mira nuestro genial lugar, ¡incluso tenemos un bar de cócteles!). Recuerde que la empresa tiene motivos diferentes a los suyos (reclutamiento, marketing, etc.). A veces incluso puede haber conflictos, que a la gente no se le permita visitar la oficina de los competidores. Si es posible, prefiero espacios de coworking y eventos "neutrales" y gracias a Open Collective puedes conseguir patrocinios para pagar el lugar con reglas justas (reclutamiento/marketing/etc) para todos.
  • Recordatorios: todos estamos ocupados y es fácil olvidar cosas. No todo el mundo está tan comprometido, motivado y entusiasmado con el evento como usted, por lo que los recordatorios periódicos mantienen a la gente interesada y ayudan a desarrollar un hábito. Encuentre una buena cadencia para los recordatorios y no se exceda ni envíe spam a las personas. Diferentes medios funcionan para diferentes personas, así que trato de cubrir la mayor cantidad posible.
  • Escasez "He notado que anunciar el evento sólo una semana antes de su celebración y tener una cantidad limitada de asientos funciona mejor que publicarlo con un mes de anticipación con capacidad para más de 100 personas" – Dmitry Zaets, BarcelonaJs
  • Ventajas: "Los obsequios son divertidos y regalar entradas para conferencias y otras cosas puede ser un buen beneficio para asistir" – Dmitry Zaets, BarcelonaJs
  • Consistencia: "Establezca un cronograma realista desde el principio. Ya sea una reunión mensual o una conferencia trimestral, la coherencia es clave. Cree una hoja de ruta, asigne responsabilidades y cumpla con el plan. Esto no solo mantiene a su audiencia comprometida sino que también ayuda a construir una comunidad confiable." – Federico Rampazzo, CDC.cy
  • Encontrar oradores: "No tenga miedo de acercarse a expertos que podrían estar dispuestos a compartir sus ideas. ¡Es probable que muchos de sus miembros tengan historias interesantes que valga la pena compartir! Puede ser una experiencia enriquecedora tanto para ellos como para la comunidad. Tomar fotografías, vídeos y grabaciones de audio de los eventos es valioso y ayuda a los oradores en su carrera como oradores, además de aumentar el alcance del evento". – Federico Rampazzo, CDC.cy