Governança para um projeto pequeno: direitos de decisão escritos antes de serem necessários

O que é

Governança é o conjunto de regras que definem quem pode decidir o quê e como uma decisão passa a ser reconhecida como tomada. Três formatos cobrem a maioria dos projetos pequenos. Um único mantenedor decide tudo e assume isso abertamente. Um grupo pequeno decide por lazy consensus, que o glossário da Apache define como uma política que presume o consentimento geral se nenhuma resposta for publicada dentro de um prazo definido, reservando a votação explícita para as questões contestadas. Um conselho detém a autoridade final: a PEP 13 dá ao Python um conselho diretor (steering council) de cinco pessoas, com ampla autoridade que, segundo o documento, o conselho procura exercer o mais raramente possível, preferindo o consenso e os processos padrão a decisões impostas, votando por maioria estrita dos membros que não se abstêm e deliberando em público sempre que possível.

Por que importa

Sem regras escritas, as disputas são resolvidas por quem fala mais alto ou pelo silêncio, os contribuidores não sabem se uma proposta foi aprovada ou apenas não encontrou oposição, e uma passagem de responsabilidade não tem em que se apoiar. As regras importam menos nos dias comuns e mais no dia em que dois mantenedores discordam sobre a API pública.

Como aplicar

• Escreva um arquivo GOVERNANCE de uma página: mantenedores por nome e por área; quem pode fazer merge do quê; a regra de decisão padrão (lazy consensus com prazo declarado para mudanças rotineiras, acordo explícito de todos os mantenedores para API pública, licença, escopo e inclusão de um mantenedor).
• Defina um critério de desempate para o caso de dois mantenedores: um responsável por área em cada módulo, ou uma palavra final rotativa, decidido agora e não no meio de uma disputa.
• Defina como um mantenedor é adicionado (proposta, prazo, acordo) e como passa a inativo ou é removido, incluindo o caso de um mantenedor que não pode ser contatado.
• Registre as decisões no lugar onde foram tomadas: a thread da issue ou do pull request, e um architecture decision record para tudo o que molda a base de código.
• Mantenha a deliberação pública, como a PEP 13 exige do seu conselho sempre que possível; uma decisão tomada em privado deve ser publicada depois, com os seus motivos.
• Permita que o arquivo seja alterado apenas pela sua própria regra e date cada mudança.

Armadilhas

Copiar uma estrutura de conselho para duas pessoas. Regras escritas e nunca aplicadas, de modo que o primeiro uso real é também o primeiro teste. Silêncio tratado como consentimento sem prazo declarado, o que deixa uma proposta passar porque ninguém a leu. Uma governança que nomeia pessoas mas não áreas, fazendo com que toda questão vá parar no fundador.