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.
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.
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.
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.
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:
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.
A primeira etapa é configurar uma organização GitHub e criar dois repositórios:
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:
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.
Agora que existe uma organização, alguns repositórios com problemas e alguma estrutura implementada, é hora de automatizar.
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:
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 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.
É 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.
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:
README.md
ou .json
no GitHub; todos podem editar, sem necessidade de CMS ou conta, etc.events
)
Todos esses recursos foram possíveis por meio da API GraphQL e pela análise dos arquivos Markdown com o analisador de corpo.
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:
Construir tudo isso exigiu muito tempo e energia e ainda faltam muitas coisas para as quais não tenho tempo:
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.