Tema: maintainership
-
Após a chegada de um relatório de vulnerabilidade: confirmar, avaliar, corrigir em privado e divulgar
Quando um relatório chega ao contato de segurança do projeto, o trabalho segue uma sequência com datas: confirmar o recebimento rapidamente, classificar (comportamento esperado, bug, pedido de funcionalidade ou vulnerabilidade), combinar um embargo com quem reportou, desenvolver a correção em privado, obter um identificador CVE e então lançar a versão e publicar um aviso que indique as versões afetadas e corrigidas e dê crédito a quem reportou. O guia de mantenedores da OpenSSF e as orientações de divulgação do GitHub descrevem esse processo; este artigo o resume para projetos com um a cinco mantenedores.
-
Triagem de issues em um projeto pequeno: conjunto fixo de labels e revisão periódica
Triagem é decidir, para cada nova issue, o que ela é, se há algo a fazer e quem age em seguida. Um vocabulário pequeno de labels em três famílias (tipo, status, área) e uma revisão curta em cadência fixa mantêm o tracker confiável; as labels padrão do GitHub (entre elas bug, enhancement, documentation, duplicate, question, wontfix, good first issue e help wanted) servem como ponto de partida.
-
Reconhecer contribuidores: uma tabela por tipo de contribuição, sem rankings
A especificação All Contributors prevê uma seção Contributors em local de destaque, com uma tabela de nome, link e categoria de contribuição, que inclui todos os tipos e níveis de contribuição, sem importar a ordem, e desaconselha excluir alguém por um suposto baixo nível de contribuição. O trailer Co-authored-by do Git dá crédito aos coautores de um commit. Juntos, permitem que um projeto pequeno reconheça documentação, triagem, design e relatos de problemas, e não apenas código integrado.
-
Cadência de lançamentos em um projeto pequeno: ciclos por tempo ou lançamento quando estiver pronto
O número da versão diz o que um lançamento promete; a política de cadência diz quando os lançamentos acontecem. O Rust lança uma versão estável a cada seis semanas, num esquema de trem com nightly, beta e stable; o Python adotou um lançamento anual de funcionalidades com a PEP 602; o Django publica versões de funcionalidades em calendário fixo e de correção conforme a necessidade. Um projeto pequeno pode seguir o mesmo modelo: versões de funcionalidades por calendário ou quando algo relevante se acumula, e versões de correção sempre que uma correção chega.
-
Um arquivo CONTRIBUTING que responde às cinco primeiras perguntas de quem chega
Antes de escrever código, quem quer contribuir pergunta: a mudança é desejada, como a proponho, o que um pull request precisa conter, quanto tempo até alguém responder e como uma mudança integrada chega aos usuários. Um arquivo CONTRIBUTING que responde a essas cinco perguntas, nessa ordem, e remete a links para o resto, tem o objetivo de evitar pull requests que seriam rejeitados por escopo ou por falta de testes.
-
Recusar um pedido de funcionalidade sem perder o contribuidor
Uma recusa que remete para um escopo documentado, chega logo, indica uma alternativa e encerra a discussão é mais gentil do que o silêncio e mantém o autor do pedido como contribuidor. Segundo os Open Source Guides, pôr as coisas por escrito facilita dizer não, e uma resposta raramente precisa de mais do que uma ou duas frases.
-
Governança para um projeto pequeno: direitos de decisão escritos antes de serem necessários
Um arquivo de governança responde quem pode fazer merge, quem resolve uma disputa de escopo, como os mantenedores são adicionados e removidos e como as próprias regras mudam. A PEP 13 do Python mostra um modelo de conselho cuja autoridade deve ser exercida raramente e com deliberação pública; o glossário da Apache define lazy consensus, em que uma proposta passa se ninguém se opuser dentro de um prazo declarado. Um projeto com um a três mantenedores precisa apenas de uma página.
-
Como mantenedores de projetos pequenos realmente gastam suas horas, e o que afastou essa divisão da escrita de código?
Pergunta em aberto: os Open Source Guides observam que mantenedores de projetos muito usados acabam programando menos e respondendo mais a issues, e recomendam documentação, saber dizer não, dividir a carga e automação; faltam medições do tempo por atividade em projetos pequenos e evidências de quais dessas medidas mudaram a divisão.
-
Transferência de mantenedor e bus factor: o que um sucessor precisa conseguir fazer no primeiro dia
Um projeto sobrevive à saída do mantenedor quando uma segunda pessoa já tem todas as contas e chaves, consegue fazer uma release só com os passos escritos e sabe onde as decisões estão registradas. A PEP 541 mostra o que acontece no PyPI sem isso: um projeto só é considerado abandonado se o dono estiver inacessível, não houver release há doze meses e a página inicial não mostrar atividade; só então pode passar a um novo dono pela regra de abandono. A transferência de repositório do GitHub leva issues, pull requests, estrelas e watchers junto com o código.
-
Suporte a várias linhas de release: quais correções vão para onde
Uma política de suporte é uma tabela de linhas de release, cada uma com um status (feature, bugfix, somente segurança, fim de vida), e uma regra que define quais classes de correção são portadas para quais linhas. O Python mantém uma série com releases de bugfix por dois anos e releases somente de segurança por mais três; o Django porta correções críticas para o último feature release e correções de segurança e perda de dados para os dois últimos, além das linhas de suporte de longo prazo; o Rust suporta apenas a versão estável mais recente. Um projeto pequeno deve publicar a tabela e adotar por padrão a promessa mais restrita que consiga cumprir.
Legível por máquina: JSON