paint-brush
GitHub e a arte de construir comunidades abertasby@patrickheneise
188

GitHub e a arte de construir comunidades abertas

Patrick Heneise11m2023/12/20
Read on Terminal Reader

Neste artigo compartilho minha experiência e ideias sobre como construir comunidades abertas. Tenho trabalhado neste conceito e nessas ferramentas para juntar as peças para a automação da comunidade e espero que isso possa ajudar você e sua comunidade a tornar as coisas mais fáceis.
featured image - GitHub e a arte de construir comunidades abertas
Patrick Heneise HackerNoon profile picture
0-item
1-item
2-item

As comunidades são difíceis. Eles são difíceis de construir, difíceis de manter e difíceis de cultivar. Mas construir comunidades tem sido uma das coisas mais gratificantes da minha carreira, porque conheci tantas pessoas incríveis e fui forçado a aprender e fazer coisas fora da minha zona de conforto.


Lembro-me de que há mais de 10 anos participei da minha primeira pequena conferência de tecnologia - CouchConf em Berlim. Felizmente houve um Meetup BerlinJS acontecendo na mesma época e fiquei impressionado com a comunidade e as pessoas. Eles têm um repositório GitHub configurado para o site e as palestras são enviadas como problemas do GitHub. Fiquei impressionado com a simplicidade e transparência do processo, então bifurquei o repositório e fundei o BarcelonaJS algumas semanas depois. Este foi o início da jornada dos meus próprios organizadores.


Uma pequena anedota de uma experiência regular e muito frustrante: você passou horas preparando, comunicando, encontrando e convidando palestrantes, encontrando e garantindo uma data e local, conversando com patrocinadores sobre comidas e bebidas, tudo para montar um grande evento. E quando chegar a hora, você estará sentado sozinho ou com uma fração das pessoas que você imaginou que viriam, porque o Meetup diz “150 pessoas confirmaram presença SIM”. E em uma rara ocasião isso foi apenas azar com o clima, mas com mais frequência, quando conversei com as pessoas depois, ouvi isto:


Isso é incrível, eu queria ter estado lá, mas não sabia!


Essa frase foi a motivação para eu começar a explorar o GitHub como uma ferramenta comunitária porque o GitHub é uma das plataformas mais incríveis para automação e é isso que você precisa fazer como organizador: automatizar tudo para publicar o evento na Eventbrite, Meetup, Twitter, Facebook, Grupos de Telegram, WhatsApp, Email, Calendário, etc. etc. e faça isso 2 semanas antes, 1 semana antes, 3 dias antes, 1 dia antes, 1 hora antes do evento para que ninguém possa dizer depois : "Eu não sabia sobre isso". Porque no final das contas, você não está fazendo isso por si mesmo, mas pela comunidade.


Durante minhas viagens, encontrei comunidades Node.js e JavaScript no Meetup com milhares de membros, mas nenhum evento futuro ou recente. Isso pode acontecer por vários motivos, mas muitas vezes é porque os organizadores não têm tempo ou mudaram para outras coisas, e é difícil encontrar um sucessor para manter as coisas funcionando. Meetup e outras plataformas são ótimas para a descoberta de comunidades e eventos, mas tornam difícil para os membros entrarem em contato com a comunidade caso um organizador não esteja mais ativo e assumirem/reanimarem a comunidade.


Como desenvolvedor, passo muito tempo no GitHub e estou familiarizado com as ferramentas e fluxos de trabalho, então comecei a explorar como usar o GitHub como uma plataforma comunitária.

Benefícios de usar GitHub para construção de comunidade

Código aberto e comunidade aberta

O primeiro e mais óbvio benefício é que os repositórios públicos no GitHub são de código aberto. Isso significa que todo o conteúdo, questões e discussões são públicos e podem ser bifurcados, copiados e reutilizados por qualquer pessoa. Isto é óptimo para as comunidades porque significa que se a comunidade for abandonada, qualquer pessoa pode desembolsá-la e continuar o trabalho. Isso também significa que se você quiser iniciar uma nova comunidade, poderá criar uma comunidade existente e adaptá-la às suas necessidades.


O GitHub possui gerenciamento de usuário/equipe/organização integrado, então você não precisa criar nada sozinho. É fácil convidar alguém para a organização ou adicionar equipes com diferentes permissões da organização.


A maioria de nós sabe como usar o GitHub e visitar o site diariamente, portanto não há necessidade de marcar sites adicionais para administração de banco de dados, gerenciamento de conteúdo ou outras ferramentas. Com o GitHub Actions, podemos executar tarefas automatizadas de acordo com uma programação ou sob demanda, e com o GitHub Pages podemos hospedar o site da nossa comunidade gratuitamente.

Construindo em Público e Transparência

Para mim, um dos benefícios mais importantes de construir uma comunidade no GitHub é a transparência total e a comunicação aberta. Tudo[1] é público, então não há necessidade de se preocupar com quem tem acesso a quê. Isso significa que qualquer pessoa pode contribuir com a comunidade e ver o que está acontecendo. Isso é ótimo para construir confiança e construir uma comunidade que seja inclusiva e acolhedora para todos.


Meu objetivo com comunidades como BarcelonaJS, CDC etc. era/é criar espaços livres e abertos para desenvolvedores compartilharem e se conectarem. E “gratuito” é onde entra a transparência. No passado, sempre mantive minhas mãos longe das contribuições financeiras. Se uma empresa quisesse patrocinar, poderia pedir comida ou bebida diretamente no local do evento, mas eu não facilitaria. Graças ao Open Collective , isto ficou muito mais fácil e agora podemos aceitar contribuições financeiras e torná-las transparentes para a comunidade. Eles são usados, por exemplo, para pagar pelo(s) domínio(s), para obter alimentos e bebidas, realizar campanhas publicitárias, etc.


[1], claro, você também pode criar um repositório privado para discussões internas de organizadores, etc.

Desvantagens e advertências

GitHub não é uma plataforma de comunidade/evento como o Meetup, então há algumas ressalvas. Eu me acostumei a tratar os problemas como "Eventos" ou "Propostas de discussão" e os Formulários de problemas do GitHub para estruturar os envios. Mas não é o ideal e leva tempo para que os recém-chegados entendam “Criar um problema para enviar uma palestra”. Não há “recursos de conforto” para escolher uma data, local em um mapa, etc. e acionar uma simples notificação por e-mail para centenas de pessoas.

A comunidade aberta (desenvolvedores)

Todo esse conceito se concentra principalmente em desenvolvedores e engenheiros, à medida que evolui em torno do GitHub e do IssueOps. Para dar uma ideia da minha experiência anterior, aqui estão algumas comunidades e conferências que ajudei a construir:


  • BarcelonaJS , 2012 - 2018
  • Hackers e fundadores Barcelona, 2012 - 2015
  • Grupo Meetup Node.js Barcelona, 2012 - 2018
  • Encontro do Couchbase Barcelona, 2012 - 2015
  • NodeConf Barcelona, 2015, 2016, 2017
  • MediterrâneoJS, 2015
  • ChipreJS 2018 - 2021
  • Comunidade de desenvolvedores de Chipre 2020 - presente


Ao construí-los, trabalhei continuamente em um conjunto de ferramentas, fluxos de trabalho e automação para facilitar a vida dos organizadores, porque é um trabalho muito difícil e muitas vezes ingrato. Então aqui está meu conceito de comunidade aberta de como construir uma comunidade pública no GitHub.

Etiquetas e estrutura

A primeira etapa é configurar uma organização GitHub e criar dois repositórios:

  1. eventos
  2. fala


Os nomes são óbvios: no repositório de eventos há modelos para criação de novos eventos , e no repositório de palestras há modelos para envio de propostas de palestras . As palestras podem ser vinculadas a eventos para construir uma agenda e, se você conseguir o envolvimento da comunidade (lembre-se: é difícil!), comentários e reações como 👍 ou ❤️ podem ser usados para votar nas palestras.


Você também pode usar um projeto GitHub para gerenciar o ciclo de vida do evento através das fases de proposta, agendamento e anúncio:

Visualização do projeto GitHub


Em Chipre, adicionámos rótulos para as diferentes regiões da ilha, mas o mais importante é que é necessário um rótulo “Aprovado”. Todos os novos problemas são criados com o rótulo “Evento”, mas somente alguém com permissão de “triagem” (equipe organizadora) pode “aprovar” o evento. Isso é importante para evitar spam e garantir que o evento seja relevante.

Rótulos de eventos do GitHub


Agora que existe uma organização, alguns repositórios com problemas e alguma estrutura implementada, é hora de automatizar.

GitEventos

GitEvents / GitEvents no GitHub remonta a 2014 e começou com o nome gitup como um "fim de semana de hack" de colaboração entre o London Node User Group (LNUG) e o Barccelona Node.js Group. Naquela época, o GitHub Actions não existia e tentamos usar Webhooks para problemas de construção de dados estruturados para sites hospedados no GitHub com base em dados do Meetup.com. A configuração foi complicada e o projeto foi abandonado por um tempo.


Hoje, GitEvents é um conjunto simples de ações do GitHub para automatizar fluxos de trabalho de problemas. "Git Ops" para encontros e eventos. Tudo o que é necessário é uma organização GitHub e um aplicativo GitHub. Alguns dos recursos são:


  • Organização inclusiva : qualquer interação com repositórios, problemas ou discussões do GitHub aciona um fluxo de trabalho para convidar o usuário para a organização do GitHub e adicioná-lo à equipe de "Membros da comunidade". As permissões são as mesmas do público, mas um pequeno “hack de crescimento e engajamento” é que você pode @mencionar todos os membros da comunidade em problemas. Isso é ótimo para anúncios, mas não deve ser abusado, caso contrário você perderá membros rapidamente.
  • Modelos de problemas : reuni um conjunto de modelos simples para eventos, palestras, respostas de código de conduta, etc. para começar rapidamente a usar o GitEvents.
  • Broadcast : são fluxos de trabalho reutilizáveis do GitHub para automatizar o marketing e tarefas comuns, como enviar e-mail/twittar/blueskying para membros, criar/atualizar eventos no Discord, EventBrite, Meetup etc.
  • ICS : é uma ação do GitHub para gerar arquivos iCal para eventos. iCal é um padrão para eventos de calendário. As pessoas podem simplesmente adicionar isso como uma assinatura ao seu calendário para se manterem atualizadas com os eventos da comunidade. Criamos um redirecionamento para o arquivo github, para que as pessoas possam assinar o calendário com um simples link: https://calendar.cdc.cy .


Tudo é "plug and play", então você pode escolher as ações que desejar e é relativamente fácil combiná-las em um fluxo de trabalho. Por exemplo, confira os fluxos de trabalho da comunidade de desenvolvedores de Chipre .


Se você gostaria de começar com GitEvents e precisa de ajuda, entre em contato em nosso servidor Discord. GitEvents é um trabalho em andamento e sempre há muito o que fazer, especialmente com integrações com outras plataformas, etc. entrar em contato.

Formulários de problemas do GitHub

Formulários de problemas ainda são um recurso relativamente pouco conhecido no GitHub. Em vez de modelos Markdown regulares, um arquivo YAML pode ser fornecido com uma configuração de formulário.

Formulário de problema do GitHub


É muito legal obter entradas estruturadas, mas uma vez salvos como "Problema", os dados são semanticamente inúteis porque são apenas Markdown. Eu experimentei marcos, cabeçalhos Markdown, rótulos etc. para adicionar informações semânticas como datas, locais etc. a um problema, mas nada funcionou bem. Então comecei a construir o GitHub Issue Forms Body Parser . Isso ajuda a analisar um problema que foi criado por meio de um formulário para extrair datas, links, imagens, listas etc. e convertê-los em dados JSON estruturados. Isso pode ser repassado diretamente para outras plataformas como Discord, EventBrite, Meetup, etc. ou usado em mailings, tweets etc.


O Issue Forms Body Parser também está disponível no npm como uma biblioteca para analisar qualquer texto Markdown. Só recentemente percebi que arquivos README.md inteiros podem ser analisados para estruturar dados de um site:


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


Esta é a consulta para recuperar o conteúdo do arquivo da ramificação main de um repositório, e você pode passá-la para o "analisador de corpo":

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


Em vez de manter outra cópia da descrição da sua comunidade, agora você pode buscar a seção About do arquivo README.md e usá-la em seu site.

API GraphQL

Com o site https://cdc.cy mais recente, eu queria explorar e ampliar os limites do que é possível com problemas, arquivos README.md e dados JSON estruturados e estou bastante satisfeito com o resultado:


  • a maior parte do conteúdo do site é obtida de arquivos README.md ou .json no GitHub; todos podem editar, sem necessidade de CMS ou conta, etc.
  • eventos futuros e passados são baseados em problemas do GitHub (problemas aprovados e rotulados como eventos no repositório events )
  • os organizadores são obtidos dos membros da equipe do GitHub
  • Os eventos podem ser anotados/aprimorados com dados de localização adequados de um arquivo de "locais comuns"
  • Os perfis dos palestrantes são inteiramente baseados nos perfis de usuário do GitHub, podemos buscar avatares, biografia (leia-me), localização, etc.
  • Podemos exibir algumas estatísticas como "número de membros da organização", "número de eventos passados/futuros" etc.


Todos esses recursos foram possíveis por meio da API GraphQL e pela análise dos arquivos Markdown com o analisador de corpo.

Resumo e perspectivas

Venho trabalhando nesse conceito há algum tempo e ele ainda muda de forma de vez em quando. Mas as ideias básicas que adotei do BerlinJS não mudaram:


  • Comunidade Aberta : tudo é público e transparente, e todos são bem-vindos (desde que sigam o Código de Conduta)
  • Eventos e Palestras/Propostas são problemas em um repositório
  • Etiquetas ajudam na estrutura e automação


Construir tudo isso exigiu muito tempo e energia e ainda faltam muitas coisas para as quais não tenho tempo:

  • integração adequada de e-mail com programações, lembretes, etc.
  • finalizar a integração EventBrite
  • adicionar integração Meetup
  • adicionar integração WhatsApp/Telegram/Slack
  • melhorar o tratamento de problemas e comentários automáticos (ou seja, lembrete do Código de Conduta, lembrete de acompanhamento, etc.)


Se você acha que isso pode ajudar você e sua comunidade e deseja se envolver na montagem do quebra-cabeça, entre em contato no Discord Server gitevents , nas discussões do GitHub ou diretamente em um dos problemas do GitHub .


Se você estiver em Chipre ou Barcelona , junte-se e apoie os grupos de desenvolvedores locais.

Pensamentos, dicas e truques dos organizadores aleatórios por experiência pessoal

  • Locais: escolher o escritório de uma empresa como local é fácil, mas tem muitas desvantagens. É fácil manipular as pessoas quando você as tem no escritório (olha só nosso lugar bacana, temos até um bar de coquetéis!). Lembre-se de que a empresa tem motivos diferentes dos seus (recrutamento, marketing, etc.). Às vezes pode até haver conflitos, que as pessoas não tenham permissão para visitar o escritório dos concorrentes. Se possível, prefiro espaços de coworking e eventos "neutros" e graças ao Open Collective você pode conseguir patrocínios para pagar pelo local com regras justas (recrutamento/marketing/etc) para todos.
  • Lembretes: estamos todos ocupados e é fácil esquecer as coisas. Nem todo mundo está tão engajado, motivado e entusiasmado com o evento quanto você, então lembretes regulares mantêm as pessoas engajadas e ajudam a criar um hábito. Encontre uma boa cadência para lembretes e não exagere e envie spam para as pessoas. Diferentes mídias funcionam para pessoas diferentes, então tento cobrir o maior número possível.
  • Escassez "Percebi que anunciar o evento apenas uma semana antes de acontecer e ter uma quantidade limitada de assentos funciona melhor do que lançar com um mês de antecedência com capacidade para mais de 100 pessoas" – Dmitry Zaets, BarcelonaJs
  • Vantagens: "Os brindes são divertidos, e distribuir ingressos para conferências e outras coisas pode ser uma ótima vantagem para participar" – Dmitry Zaets, BarcelonaJs
  • Consistência: "Estabeleça um cronograma realista desde o início. Seja um encontro mensal ou uma conferência trimestral, a consistência é fundamental. Crie um roteiro, atribua responsabilidades e siga o plano. Isso não apenas mantém seu público envolvido, mas também ajuda na construção uma comunidade confiável." –Federico Rampazzo, CDC.cy
  • Encontrar palestrantes: "Não tenha medo de abordar especialistas que possam estar dispostos a compartilhar suas idéias. Muitos de seus membros provavelmente terão histórias interessantes que valem a pena compartilhar! Pode ser uma experiência enriquecedora tanto para eles quanto para a comunidade. Tirar fotos, vídeos, gravar áudio dos eventos é valioso e auxilia os palestrantes na carreira de palestrante, além de aumentar o alcance do evento.” –Federico Rampazzo, CDC.cy