O que significa ser um mantenedor?
Se você mantém um projeto open source que muitas pessoas utilizam, você irá notar que está codificando menos e respondendo mais issues.
Nos primeiros estágios de um projeto, você está experimentando novas ideias e tomando decisões baseadas no que você quer. À medida que a popularidade do seu projeto aumenta, você terá a percepção que está trabalhando mais com seus usuários e contribuidores.
Manter um projeto exige mais do que simplesmente codificar. Há tarefas que são geralmente inesperadas, porém muito importantes para um projeto em crescimento. Reunimos algumas maneiras de tornar sua vida mais fácil, indo desde os processos de documentação até formas de alavancar sua comunidade.
Documentando seus processos
Escrever é uma das coisas mais importante que você pode fazer como um mantenedor.
A documentação não só clareia seu próprio pensamento, como também ajuda outras pessoas a entenderem o que você precisa ou espera, antes mesmo delas perguntarem.
Escrever facilita dizer “não” quando alguma coisa não se encaixa no seu escopo. Assim como torna mais fácil a participação e a ajuda das pessoas. Você nunca saberá quem estará lendo ou usando o seu projeto.
Mesmo que você não use parágrafos completos, pontuar os principais tópicos é melhor do que não escrever nada.
Lembre-se de manter a sua documentação atualizada. Se você não está disponível para fazer isso, exclua a sua documentação desatualizada ou deixe explícito tal informação para que os contribuidores saibam que atualizações são bem-vindas.
Escrevendo a visão do seu projeto
Inicie escrevendo os objetivos do seu projeto. Adicione eles ao README, ou crie um arquivo separado chamado VISÃO. Caso existam outros artefatos que possam ajudar, como o roadmap do projeto, torne-os públicos também.
Ter uma visão clara e documentada mantém você focado e ajuda a evitar a “fuga de escopo” das contribuições de outras pessoas.
Por exemplo, @lord descobriu que ter uma visão de projeto o ajudou a definir em quais requests gastaria seu tempo. Como um novo mantenedor, ele se arrependeu de não ter seguido o escopo quando recebeu sua primeira request para o Slate.
Comunique suas expectativas
Escrever regras pode ser estressante. Algumas vezes você pode sentir como se estivesse policiando o comportamento das outras pessoas ou acabando com a felicidade delas.
Entretanto, boas regras escritas e aplicadas, empoderam os mantenedores. Elas previnem você de ser arrastado a fazer coisas que não queria.
Muitas pessoas que tem contato com seu projeto não sabem nada sobre você ou sobre suas circunstâncias. Elas podem assumir que você é pago para trabalhar nisso, especialmente se é alguma coisa que elas usam regularmente e dependem. Talvez em algum momento você tenha dedicado muito tempo ao seu projeto, mas agora você está ocupado com um novo trabalho ou com um membro familiar.
Tudo isso é perfeitamente aceitável! Apenas tenha certeza de que as pessoas saibam disso.
Se a manutenção de seu projeto é em tempo parcial ou puramente voluntária, seja honesto(a) sobre quanto tempo você tem. Isso não é o mesmo que o quanto de tempo que você acha que o projeto requer, ou quanto tempo os outros querem que você gaste.
Aqui estão algumas regras que valem a pena escrever:
- Como uma contribuição é analisada e aceita (Você precisa de testes? Um template de issue?)
- Os tipos de contribuição que você irá aceitar (Você só quer ajuda em uma certa parte de seu código?)
- Quanto é apropriado seguir (por exemplo, “Você pode esperar a resposta de um mantenedor dentro de 7 dias. Se não obtiver nada dele, sinta-se livre para fazer um ping no tópico.”)
- Quanto tempo você gasta no projeto (por exemplo, “Nós só gastamos 5 horas por semana neste projeto”)
Jekyll, CocoaPods, e Homebrew são vários exemplos de projetos com regras básicas para mantenedores e contribuidores.
Mantenha a comunicação pública
Não se esqueça de documentar suas interações também. Onde você puder, mantenha a comunicação sobre seu projeto pública. Se alguém tentar contatar você privativamente para discutir uma feature request ou um suporte necessitado, dirija ela ao canal de comunicação público, como uma lista de e-mail ou um issue tracker.
Se você encontrar outros mantenedores, ou tomar uma importante decisão em particular, documente essas conversas em público, mesmo que sejam apenas suas anotações.
Deste modo, qualquer um(a) que adentrar na comunidade terá acesso à mesma informação que alguém que já se encontra na mesma há anos.
Aprendendo a dizer não
Você escreveu as coisas. Idealmente, todo mundo iria ler sua documentação, porém na realidade, você terá que relembrar os outros que esse conhecimento existe.
Entretanto, estar tudo escrito ajuda a despersonalizar situações em que você precisa impor suas regras.
Dizer “não”, não é divertido, mas “A sua contribuição não corresponde aos critérios deste projeto” soa menos pessoal que “Eu não gosto de sua contribuição”.
Como mantenedor, você irá se deparar com diversas situações em que terá que dizer “não”: solicitações de funcionalidades que não se encaixam no escopo, alguém provocando uma discussão, trazendo trabalho desnecessário aos outros.
Mantenha o diálogo amigável
Um dos mais importantes lugares em que você irá praticar dizer não é em suas filas de issues e pull requests. Como um mantenedor de projeto, você irá inevitavelmente receber sugestões que não deseja aceitar.
Talvez uma contribuição mude o escopo do projeto ou não corresponde à sua visão. Talvez a ideia seja boa, porém a implementação seja pobre.
Independentemente do motivo, é possível lidar de forma diplomática com contribuições que não atendem aos padrões do seu projeto.
Se você recebe uma contribuição que não deseja aceitar, sua primeira reação pode ser ignorá-la ou fingir que não a viu. Fazer isso pode machucar o sentimento das outras pessoas e até mesmo desmotivar outros potenciais contribuidores em sua comunidade.
Não deixe uma contribuição indesejada aberta porque você se sente culpado ou quer ser legal. Com o passar do tempo, suas issues e PRs não respondidas farão o trabalho em seu projeto pareça mais estressante e intimidador.
É melhor fechar imediatamente as contribuições que você sabe que não deseja aprovar. Se seu projeto já sofre com um grande backlog, @steveklabnik tem sugestões para como realizar a triagem de issues eficientemente.
Em segundo lugar, ignorar contribuições envia um sinal negativo para sua comunidade. Contribuir para um projeto pode ser intimidador, especialmente se é a primeira vez de alguém. Mesmo que você não aceite a contribuição dele(a), dê reconhecimento à pessoa por trás dela e agradeça pelo interesse. É um grande elogio!
Se você não deseja aceitar uma contribuição:
- Agradeça ele(a) pela contribuição
- Explique porque não se encaixa no escopo do projeto e ofereça sugestões claras de melhorias, se você for capaz. Seja gentil, mas firme.
- Link para uma documentação relevante, se houver. Se você notar repetidas solicitações por coisas que você não deseja aceitar, adicione elas à sua documentação para evitar ficar se repetindo.
- Feche a request
Você não precisará de mais de 1-2 sentenças para responder. Por exemplo, quando um(a) usuário(a) do celery reporta um erro relacionado ao Windows, @berkerpeksag respondeu com:
Se pensar em dizer “não” aterroriza você, você não está sozinho. Como @jessfraz relata
Eu conversei com mantenedores de vários projetos de código aberto diferentes, Mesos, Kubernetes, Chromium, e todos concordam que uma das partes mais difíceis de ser um mantenedor é dizer “Não” aos patches que você não quer.
Não se sinta envergonhado em não querer aceitar a contribuição de alguém. A primeira regra do open source de acordo com @shykes é: “Não é temporário, sim é para sempre.” Embora a empatia com o entusiasmo de outra pessoa seja uma coisa boa, rejeitar uma contribuição não é o mesmo que rejeitar a pessoa por trás dela.
Por fim, se uma contribuição não é boa o suficiente, você não possui a obrigação de aceitá-la. Seja gentil e responsivo quando as pessoas contribuírem com seu projeto, porém aceite somente mudanças que você realmente acredita que tornarão seu projeto melhor. Quanto mais você pratica dizer não, mais fácil se torna. Juro.
Seja proativo
Para reduzir a quantidade de contribuições indesejadas, em primeiro lugar, explique, no guia de contribuição, o processo de submissão e aceitação das contribuições do seu projeto.
Se você está recebendo muitas contribuições de baixa qualidade, exija que esses contribuidores executem alguns passos antes, por exemplo:
- Preencher um template/checklist para issues ou PRs
- Abrir uma issue antes de submeter uma PR
Se eles não seguirem suas regras, feche a issue imediatamente e aponte para sua documentação.
Embora essa abordagem possa parecer indelicada a princípio, ser proativo é, na verdade, bom para as duas partes. Isso reduz as chances de alguém se esforçar durante horas de trabalho em uma pull request que você não irá aceitar. E além disso, torna seu fluxo de trabalho mais fácil de gerenciar.
Algumas vezes, quando você diz não, um potencial contribuidor pode chatear-se ou criticar sua decisão. Se o comportamento dele se tornar hostil, siga os passos para amenizar a situação ou até mesmo remova-o de sua comunidade, se ele não pretende colaborar de forma construtiva.
Abrace a mentoria
Talvez alguém em sua comunidade, regularmente submeta contribuições que não casam com os padrões de seu projeto. Pode ser frustrante para ambas as partes passar por rejeições repetidamente.
Se você perceber que alguém está entusiasmado com seu projeto, mas necessita de um pouco de polimento, seja paciente. Explique claramente em cada situação porque as contribuições deles não atendem as expectativas do projeto. Tente mostrá-los uma tarefa mais fácil ou menos ambígua, como uma issue marcada como “good first issue,” para que eles deem seus primeiros passos. Se você tiver tempo, considere ensiná-los a realizar sua primeira contribuição, ou encontre alguém em sua comunidade que possa estar disposto a orientá-los.
Alavanque sua comunidade
Você não precisa fazer tudo sozinho. A comunidade do seu projeto existe por uma razão! Mesmo que você ainda não tenha uma comunidade de colaboradores ativos, se dispuser de muitos usuários, coloque-os para trabalhar.
Compartilhe a carga de trabalho
Se você está procurando por outras pessoas, comece perguntando.
Quando perceber novos contribuidores fazendo contribuições repetidamente, reconheça o trabalho deles oferecendo mais responsabilidades. Documente como os outros podem crescer em termos de liderança no projeto se assim eles desejarem.
Encorajar os outros a compartilhar a propriedade do projeto pode rapidamente reduzir sua própria carga de trabalhos, assim como @lmccart descobriu no projeto dela, p5.js.
Se você precisar se afastar de seu projeto, seja por um hiato ou permanentemente, não há vergonha em pedir para alguém assumir o controle para você.
Se outras pessoas estão entusiasmadas com a sua direção, conceda-lhes acesso de commit ou formalmente entregue o controle a outra pessoa. Se alguém “deu fork” em seu projeto e está ativamente mantendo-o em outro lugar, considere ligar o fork ao seu projeto original. É ótimo que tantas pessoas queiram que seu projeto continue vivo!
@progrium descobriu que documentar a visão de seu projeto, Dokku, ajudou esses objetivos a sobreviverem, mesmo depois de seu afastamento:
Eu escrevi um página wiki descrevendo o que queria e porque eu queria. Por alguma razão, para minha surpresa, os mantenedores começaram a fazer o projeto andar naquela direção! As coisas aconteceram exatamente da forma que eu faria? Nem sempre. Mas ainda trouxera o projeto para mais próximo do que escrevi.
Deixe que os outros construam as soluções que precisam
Se um colaborador em potencial possui uma opinião diferente sobre o que o seu projeto deve fazer, convém incentivá-lo gentilmente a trabalhar em seu próprio fork.
Realizar o fork de um projeto não precisa ser uma coisa ruim. A capacidade de copiar e modificar projetos é uma das melhores coisas no open source. Incentivar os membros de sua comunidade a trabalharem em seus próprios forks pode fornecer a saída criativa de que precisam, sem entrar em conflito com a visão de seu projeto.
O mesmo se aplica a um usuário que realmente quer uma solução que você simplesmente não tem recurso suficiente para construir. Oferecer APIs e hooks de personalização pode ajudar as outras pessoas a atender as suas próprias necessidades, sem precisar que modificar o código fonte diretamente. @orta descobriu que estimular a criação de plugins para CocoaPods levou à “algumas das ideias mais interessantes”:
É quase inevitável que, quando um projeto se torna grande, os mantenedores precisam tornar-se mais conservadores sobre como eles introduzem código novo. Você se torna bom em dizer “não”, mas muitas pessoas possuem necessidades legítimas. Então, em vez disso, você acaba transformando sua ferramenta em uma plataforma.
Traga os robôs
Assim como há tarefas com as quais outras pessoas podem te ajudar, há também tarefas que nenhum humano deveria fazer. Os robôs são seus amigos. Utilize-os para tornar sua vida de mantenedor mais fácil.
Exija testes e outras verificações para aumentar a qualidade de seu código
Uma das mais importantes formas de automatizar seu projeto é adicionando testes.
Testes ajudam os contribuidores a sentirem-se confiantes de que eles não quebrarão nada. Testes também tornam mais fácil, para você, revisar e aceitar contribuições rapidamente. Quanto mais responsivo você é, mais engajada sua comunidade poderá ser.
Configure testes automáticos que irão executar em todas as contribuições recebidas e garanta que seus teste poderão ser facilmente executados localmente por seus contribuidores. Exija que todas as contribuições de código passem em seus testes antes que possam ser submetidas. Você ajudará a definir um padrão mínimo de qualidade para todas as submissões. Verificações de status obrigatórias no GitHub podem ajudar a garantir que nenhuma mudança seja aceita sem passar por seus testes.
Se você adicionar testes, tenha certeza de ter explicado como eles funcionam em seu arquivo de contribuição.
Use ferramentas para automatizar tarefas básicas de manutenção
A boa notícia sobre manter um projeto popular é que outros mantenedores já enfrentaram problemas similares e construíram soluções para isso.
Existem uma variedade de ferramentas disponíveis para ajudar a automatizar alguns aspectos do trabalho de manutenção. Veja alguns exemplos:
- semantic-release automatiza suas releases
- mention-bot menciona potenciais reviwers para pull requests
- Danger ajuda a automatizar o code review
Para relatório de bugs e outras contribuições comuns, o GitHub possui Modelos de Issue e Modelos de Pull Request, que você pode criar para simplificar a comunicação que você recebe. @TalAter fez o guia Choose Your Own Adventure, para ajudar você a escrever seus modelos de issue e PR.
Para gerenciar suas notificações de e-mail, você pode configurar filtros de e-mail para organizar por prioridade.
Se você deseja ir um pouco além, style guides e linters podem padronizar as contribuições do projeto e torná-las mais fáceis de revisar e aceitar.
Entretanto, se seus padrões são muito complicados, elas podem aumentar as barreiras para contribuição. Tenha certeza de adicionar apenas as regras suficientes para tornar a vida de todo mundo mais fácil.
Se você não está certo sobre quais ferramentas usar, procure ver o que outros projetos populares fazem, especialmente aqueles do seu ecossistema. Por exemplo, como é o processo de contribuição para outros módulos do Node? Usar ferramentas e abordagens semelhantes também tornará seu processo mais familiar para seus contribuidores-alvo.
Não há problema em pedir pause
Trabalhar com Open Source uma vez lhe trouxe alegrias. Talvez agora esteja começando a fazer você se sentir esquivo ou culpado.
Talvez você se sinta sobrecarregado ou um sentimento crescente de pavor quando você pensa sobre seus projetos. E enquanto isso, as issues e pull requests se acumulam.
O burnout é um problema real e onipresente no trabalho open source, especialmente entre mantenedores. Como um mantenedor, sua felicidade é um requisito não-negociável para a sobrevivência de qualquer projeto open source.
Embora não seja preciso dizer, dê uma pausa! Você não deve esperar se sentir esgotado para tirar férias. @brettcannon, desenvolvedor do core do Python, decidiu tirar um mês de férias após 14 anos de trabalhos em software open source.
Assim como qualquer outro tipo de trabalho, fazer pausas regulares manterão você revigorado, feliz e excitado sobre seu trabalho.
Algumas vezes, pode ser difícil tirar férias de um trabalho open source quando parece que todo mundo precisa de você. As pessoas podem até tentar fazer você se sentir culpado por estar se afastando.
Faça seu melhor para dar suporte para seus usuários e sua comunidade enquanto estiver afastado do projeto. Se você não conseguir encontrar o apoio que precisa, tire um tempo mesmo assim. Certifique-se de comunicar quando não estiver disponível, para que as pessoas não fiquem confusas com sua falta de responsividade.
Intervalos sem aplicam a mais do que apenas as férias. Se você não quer trabalhar em open source nos finais de semana, ou durante suas horas de trabalho normais, comunique aos outros, então eles saberão que não devem incomodá-lo.
Cuide-se primeiro!
Manter um projeto popular requer habilidades diferentes das primeiras etapas de crescimento, mas não é menos recompensador. Como um mantenedor, você praticará a liderança e suas habilidades pessoais em um nível que poucas experimentam. Embora nem sempre seja fácil gerenciá-lo, estabelecer limites claros e apenas aceitar o que lhe é mais conveniente ajudará você a se manter feliz, atualizado e produtivo.
