https://a.storyblok.com/f/270183/90866/4c00d8485f/blog_survival-guide_hacktoberfest_1200x600.png

Como sobreviver ao Hacktoberfest: um guia para mantenedores

Publicado em May 10, 2021

Tempo de leitura: 5 minutos

Feliz Hacktoberfest a todos! Colaboradores, espero que estejam se divertindo muito aprendendo novas habilidades e descobrindo projetos nos quais possam fazer a diferença. Mantenedores, o post de hoje é especialmente para vocês. Esperamos que as mudanças nas regras tragam uma melhor qualidade de pull requests para seus projetos, mas ainda assim pode ser bastante trabalho. Sou mantenedor há muito tempo e, hoje, gostaria de compartilhar algumas dicas que espero que ajudem vocês nessa jornada.

A Vonage está muito animada por ser parceira do Hacktoberfest 2020. Nós não somos novatos no mundo do código aberto, já que nossas bibliotecas, trechos de código e demonstrações estão todos no GitHub. Para mergulhar de cabeça nas comemorações, não deixe de conferir nossa página do Hacktoberfest para saber mais sobre tudo o que planejamos!

Vamos falar sobre prioridades

Os mantenedores de projetos de código aberto realizam esse trabalho principalmente em seu tempo “livre”, e é uma carga e tanto. Não se trata apenas do Hacktober, e grande parte desse trabalho pode passar bastante despercebida. Neste Hacktoberfest, especialmente com os eventos globais que estão acontecendo ao nosso redor, é importante refletir sobre suas prioridades e não perdê-las de vista!

Sugiro que você, seu projeto e, em seguida, seus colaboradores, nessa ordem, constituam uma boa sequência de prioridades. Um projeto não é nada sem mantenedores, e muitos deles são equipes compostas por uma única pessoa. Os objetivos e a meta do projeto são uma prioridade importante; não há pressão para ampliar o escopo ou mudar o rumo do projeto só porque chegou uma solicitação de pull com essa proposta. A beleza do código aberto é que as pessoas podem usar seus próprios forks como base para um novo projeto, caso não gostem da maneira como você conduz as coisas! E, finalmente, os colaboradores; o Hacktoberfest atrai muitos novos colaboradores, mas queremos formá-los para que se tornem colaboradores de verdade, não crianças mimadas. Portanto, se eles precisarem ler as diretrizes do projeto antes de contribuir, diga isso a eles, em vez de ter que refazer todo o trabalho sozinho.

Como lidar com a fadiga de notificações

O Hacktoberfest agora é opcional, mas se você decidir participar, é fácil se sentir sobrecarregado, especialmente em um projeto de grande visibilidade ou que já esteja bastante ocupado. O segredo para lidar com isso é gerenciar suas notificações. E não, uma regra de e-mail que simplesmente arquive ou exclua tudo que contenha o nome do seu projeto não é a solução!

Add a filter to file all incoming mail with the word GitHub inAdd a filter to file all incoming mail with the word GitHub in

Reserve um tempo para configurar suas notificações do GitHub, a fim de garantir que você seja notificado quando desejar e não receba muitas notificações irrelevantes. Você também pode direcionar notificações de diferentes organizações para endereços de e-mail distintos, o que pode ser muito útil.

Configurar e encaminhar e-mails

O GitHub possui uma excelente documentação de ajuda, por isso não vou repetir o conteúdo dela aqui, mas vou indicar os recursos que considero mais úteis!
Primeiro, você pode vincular vários endereços de e-mail a uma única conta do GitHub, o que é útil se você usa sua conta do GitHub para projetos de trabalho ou se utiliza um endereço de e-mail diferente para um projeto específico de código aberto. Dê uma olhada na documentação sobre como verificar endereços de e-mail adicionais no GitHub.

Em seguida, configure para que as notificações corretas sejam enviadas para o endereço de e-mail correto. Isso fica na seção “roteamento personalizado” da configuração de notificações e, é claro, há uma excelente documentação sobre o roteamento de e-mails no GitHub.

Assistir e deixar de assistir

A função de “acompanhar” um repositório é muito útil. Se houver um projeto sobre o qual você queira receber todas as notificações, clique no botão “Acompanhar”, na parte superior, e selecione “Acompanhando”. Isso é útil se você precisar acompanhar as atividades em um repositório específico.

screenshot showing the GitHub watch button and options: not watching, releases only, not watching, ignoring

Talvez ainda mais valiosa seja a possibilidade de “deixar de acompanhar” um projeto! Como sou responsável por parte da manutenção do GitHub no trabalho, tenho acesso a muitos repositórios e, por padrão, se você tem acesso, acaba recebendo as notificações! Isso pode ser bem incômodo, como você pode imaginar; por isso, o mesmo botão “Acompanhar” oferece outras opções — a configuração padrão é “Não acompanhando”, então você receberá notificações sobre suas próprias issues/PRs ou se for mencionado. Você também pode definir como “Ignorando” se estiver sendo envolvido quando não quer.

Inscrever-se e cancelar a inscrição

No nível de cada repositório, você também pode receber notificações sem precisar comentar na discussão para ser considerado “participante”. Procure o botão à direita chamado “Inscrever-se”, na seção “Notificações”. Mais uma vez, também existe a opção contrária! Suponha que você tenha participado de uma discussão sobre um assunto pelo qual não tem mais interesse em receber notificações. Nesse caso, você pode “Cancelar inscrição” em apenas uma issue ou pull request sem precisar cancelar a inscrição em todo o repositório.

Aja rapidamente

Se uma solicitação de pull não for útil ou não atender aos objetivos do projeto, não tenha medo de rejeitá-la. O FAQ do Hacktoberfest é seu aliado nesse caso. Seja sempre cordial — mas respostas rápidas são valiosas se você tiver disponibilidade para acompanhar as coisas a cada poucos dias. Se uma solicitação de pull puder ser tornada aceitável — por exemplo, porque faz com que a compilação falhe, mas pode ser corrigida —, ofereça feedback ao seu novo colaborador explicando o que seria necessário para que a solicitação de pull esteja pronta para fusão. Se for uma alteração que você não deseja (um emoji para decorar seu README parece ser uma contribuição popular), então diga isso e feche a solicitação.

O código aberto nem sempre é um ambiente acolhedor, e como atuamos publicamente, as pessoas que observam ficam com uma boa impressão dos nossos projetos pela maneira como interagimos com elas. Reserve um tempo para agradecer às pessoas por suas contribuições! Mesmo que a solicitação de pull não valha o tempo que você gastou lendo-a, um simples “Isso não parece ser útil para o projeto; por que não dá uma olhada na lista de issues para ter algumas ideias?” é muito mais acolhedor do que simplesmente fechar a solicitação sem nenhuma comunicação ou explicação.

Obrigado

A propósito desses agradecimentos aos colaboradores, gostaria de encerrar agradecendo a você, o mantenedor. É um equívoco comum pensar que os projetos de código aberto são mantidos por alguma figura incrível, distante e heróica. Na verdade, nós, que dedicamos nosso tempo e energia a isso, somos pessoas reais com vidas reais.

Obrigado por tudo o que você faz; o código aberto muda o mundo e, à sua maneira, você está contribuindo para que isso aconteça.

Compartilhar:

https://a.storyblok.com/f/270183/250x250/e3d3b71060/lornajane.png
Lorna MitchellEx-funcionários da Vonage

Lorna é engenheira de software e tem um vício incurável por escrever em blogs. Ela tenta domar as palavras e o código na mesma medida.