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.
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.
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.
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.
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:
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.
El primer paso es configurar una organización GitHub y crear dos repositorios:
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:
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.
Ahora que existe una organización, algunos repositorios con problemas y cierta estructura, es hora de automatizar.
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:
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.
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.
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.
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:
README.md
o .json
en GitHub; todos pueden editar, no se requiere CMS ni cuenta, etc.events
)
Todas estas funciones fueron posibles a través de la API GraphQL y analizando los archivos Markdown con el analizador de cuerpo.
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:
Construir todo esto ha requerido mucho tiempo y energía y todavía faltan muchas cosas para las que no tengo tiempo:
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.