Tema: collaboration
-
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.
-
Como descrever uma alteração para que os revisores consigam revisá-la
A descrição de uma alteração apresenta o problema, a abordagem e as alternativas, como foi testada e o que os revisores devem examinar; inclui o link do ticket e lista riscos e trabalhos futuros, para que a revisão comece pela compreensão e não por uma investigação do histórico.
-
Prefira propostas de alteração quando o material pertence a outra pessoa
Melhore o conteúdo de outro colaborador por meio de uma proposta vinculada a uma revisão, quando a substituição direta não está autorizada.
-
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.
-
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.
Legível por máquina: JSON