Tema: open-source
-
Um dia agendado para documentação atrai mais contribuidores de primeira viagem do que um convite permanente para ajudar na documentação
Hipótese: um projeto que anuncia um dia único, com uma lista selecionada de pequenas issues de documentação, mantenedores disponíveis para revisão no mesmo dia e o rótulo good first issue em cada tarefa recebe mais alterações de documentação integradas (merged) de pessoas que nunca tinham contribuído do que a mesma lista deixada aberta o ano inteiro; propõe-se comparar com o histórico do próprio projeto.
-
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.
-
Descontinuar uma função em uma biblioteca: avisar, documentar a substituta e remover no prazo definido
Uma descontinuação em biblioteca tem quatro partes: uma substituta que exista antes de tudo, um aviso em tempo de execução mais uma nota na documentação com a versão e a substituta, uma entrada no changelog e uma versão de remoção fixada de antemão por política. A PEP 387 exige um período de descontinuação de pelo menos dois anos no ciclo anual do Python e descreve uma descontinuação leve (soft deprecation) apenas na documentação; o Django remove os shims no mínimo duas versões de funcionalidades após o aviso.
-
Repositórios cujo setup é feito com um único comando verificado recebem mais contribuições de estreantes do que repositórios com uma lista de passos manuais
Hipótese: o README do "Scripts To Rule Them All", do GitHub, afirma que reduzir o atrito no setup é fundamental para contribuições mais rápidas e satisfatórias. A proposta reformula essa afirmação de forma mensurável e prevê que repositórios com um único comando de setup que se autoverifica apresentam, em relação a repositórios pareados com passos manuais no README, mais pull requests de contribuidores estreantes, uma parcela maior delas aprovada no CI já no primeiro push e menos issues relacionadas ao setup.
-
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.
-
Open source no IBM i: yum, bash como shell padrão e inicialização do daemon SSH
A pilha open source suportada pela IBM para o IBM i (Node.js, Python, git, bash e outros) é instalada como RPMs em /QOpenSys/pkgs por meio do yum, traz o bash como shell interativo recomendado e só fica acessível remotamente depois que o daemon SSH é iniciado explicitamente com STRTCPSVR *SSHD.
Legível por máquina: JSON