# Maintainers

English · Português (Brasil) · Deutsch · Français · 简体中文 · 日本語

Este documento define as regras para se tornar, atuar como e deixar o cargo de Maintainer de `nexu-io/open-design`. A composição individual do Core Team é mantida internamente e não é enumerada aqui — o que importa publicamente são as regras pelas quais todos jogam. > **Status**: v1, redigido em 2026-05-11. Documento complementar ao [`CONTRIBUTING.md`](CONTRIBUTING.md#becoming-a-maintainer) — esse arquivo direciona contribuidores para cá em busca das regras completas. --- ## Papéis | Papel | Permissões | |---|---| | **Contributor** | Qualquer pessoa com pelo menos 1 merged PR. Sem permissões especiais. | | **External Maintainer** | Um contribuidor da comunidade promovido conforme as regras abaixo. Pode revisar, dar approve, fechar/reabrir issues e fazer self-assign de issues. **Não pode clicar no merge button** — isso fica com o Core Team. | | **Core Team** | Time interno do Open Design. Possui acesso total de escrita ao repositório e é a autoridade final em decisões de governança. Composição mantida internamente. | O restante deste documento trata dos **External Maintainers**, salvo indicação em contrário. --- ## O que um Maintainer pode fazer que um Contributor não pode | Ação | Contributor | Maintainer | |---|:---:|:---:| | Dar approve em um PR | ⚠️ conta como comentário, **não** como o approval exigido | ✓ conta como o approval exigido para o merge | | Fechar / reabrir issues | Apenas issues que ele mesmo abriu | ✓ qualquer issue | | Fazer self-assign em issues abertas e sem responsável (P0 primeiro) | ✗ | ✓ | ### Requisitos para merge Qualquer PR — independentemente de quem o tenha autorado — precisa **dos três**: 1. Sem conflitos de código. 2. CI totalmente verde. 3. Pelo menos um approval de um Maintainer ou de um membro do Core Team. O approval de um Maintainer é o caminho que a maioria dos PRs segue até o merge — é a forma mais direta pela qual a confiança em um Maintainer aparece no dia a dia do projeto. --- ## Como se tornar um Maintainer Há **três** critérios de entrada. Todos os três precisam ser atendidos. ### 1. Volume de contribuição - **≥ 20 merged PRs** em `nexu-io/open-design`. Este é um piso flexível, não uma passagem automática. Atingir 20 PRs te coloca em consideração; isso não garante o papel. ### 2. Qualidade da conta (anti-sock-puppet, anti-bot) Avaliamos o perfil do candidato no GitHub em sete dimensões. **Passe em pelo menos 5 das 7 linhas de admissão e não acione nenhuma linha de veto.** | # | Dimensão | Linha de admissão | Linha de veto | |---|---|---|---| | 1 | Idade da conta no GitHub | ≥ 1 ano | < 90 dias | | 2 | Repositórios públicos | ≥ 3 | 0 | | 3 | Seguidores | ≥ 10 | < 3 | | 4 | Razão seguidores / seguindo | > 0,30 | < 0,05 (padrão típico de follow-farm) | | 5 | Completude do perfil | Avatar personalizado **e** pelo menos um entre bio / company / blog / twitter | Avatar padrão **e** todos os campos bio/company/blog vazios | | 6 | Atividade entre projetos | Pelo menos um merged PR ou atividade sustentada de issue/star em **outro** repositório público | Merged PRs apenas neste repositório | | 7 | Situação da conta | Sem restrições da plataforma GitHub (spam/banned/restored) | Qualquer uma das anteriores | #### Dispensa para projeto inicial (expira automaticamente quando o repositório completa 6 meses) Enquanto `nexu-io/open-design` tiver menos de seis meses desde o commit inicial, o veto de **atividade entre projetos** (#6) pode ser dispensado por consenso do Core Team quando: - As dimensões 1, 2, 3 e 5 estiverem claramente acima da linha de admissão; **e** - A qualidade dos PRs do candidato neste repositório for julgada alta na revisão prática feita pelo Core Team. A dispensa precisa ser registrada no histórico interno do Core Team junto com o nome do candidato e a data. Após o repositório completar seis meses, esta cláusula de dispensa deixa de estar disponível. ### 3. Qualidade da contribuição (julgamento do Core Team) Este critério é qualitativo e não baseado em fórmula. O Core Team observa: - **Qualidade do código** dos merged PRs (correção, disciplina de escopo, respeito aos limites do repositório). - **Qualidade das revisões** em quaisquer comentários de review deixados em PRs de outras pessoas. - **Participação na comunidade** — Discussions, triagem de issues, engajamento no Discord. - **Sinal de colaboração** — receptividade a feedback, disposição para revisar. Atender aos dois primeiros critérios te coloca no pool de candidatos. Atravessar este terceiro limiar é o que te leva à indicação. ### Processo de seleção 1. Um membro do Core Team levanta o nome do candidato internamente. 2. O Core Team chega a um consenso. 3. Um membro do Core Team faz contato em particular para confirmar que o candidato aceita. 4. Onboarding. 5. Anúncio público. Não há PR de indicação, nem votação pública, nem mandato fixo. A intenção é ser o **inverso do modelo de approver-vote do K8s/Apache** — no início da vida do projeto, um consenso leve do Core Team se move mais rápido e produz a mesma qualidade de resultado. Quando o grupo de Maintainers passar de cinco External Maintainers, esta seção será revisitada. --- ## Responsabilidades e expectativas **Não há cotas rígidas.** Sem contagem semanal de PR-reviews, sem taxa mínima de triagem de issues, sem SLA para tempo de resposta. Ser Maintainer é um reconhecimento de confiança, não um trabalho não remunerado. O que pedimos, em espírito: - Dê approve em PRs para os quais você tem o contexto; abstenha-se quando não tiver. - Honre os requisitos de merge (§ "Requisitos para merge") — seu approval é um sinal real, não um carimbo automático. - Mantenha o `#maintainers` informado se você for ficar fora por um período prolongado. - Trate o roadmap ainda não público compartilhado em `#maintainers` como confidencial. Se o Core Team observar um padrão de comportamento ruim (approvals automáticos, fechamentos maliciosos de issues, vazamento de roadmap não anunciado, etc.), as permissões são revogadas conforme § "Step-down — por justa causa". --- ## Acesso exclusivo de Maintainer Além das permissões de repositório listadas acima, os Maintainers recebem algumas coisas que a comunidade mais ampla não recebe: - **Canal `#maintainers` no Discord** — um espaço de trabalho privado compartilhado com o Core Team. Usado para previews de design, rascunhos de RFC e coordenação interna sobre a parte ainda não pública do roadmap. - **Roadmap confidencial** — visibilidade antecipada de trabalhos que ainda não foram anunciados. Os Maintainers concordam em tratar seu conteúdo como confidencial até que um membro do Core Team o anuncie publicamente. - **Linha direta com o Core Team** — suas mensagens em `#maintainers` recebem uma resposta mais rápida e substantiva do que em Discussions públicas, e o Core Team genuinamente solicita o input dos Maintainers em decisões de arquitetura e roadmap. - **Selo de Maintainer** — uma marca pública de confiança no seu perfil do GitHub e nas superfícies do repositório relacionadas a MAINTAINERS (será disponibilizado assim que o recurso de badge do GitHub estiver implementado). - **Reconhecimento público na promoção** — anúncio no Twitter, no GitHub Discussions e no Discord quando você entra. --- ## Step-down Ser Maintainer não é um cargo vitalício. Há três caminhos de saída. ### Step-down voluntário (graceful) - O Maintainer envia mensagem ao Core Team ou posta em `#maintainers`. - As permissões são revogadas em até 24 horas. - O Maintainer passa para o status de **Emeritus**. - Nenhuma justificativa pública é exigida. ### Transição por inatividade Um Maintainer é considerado para transição por inatividade quando **qualquer** das condições abaixo ocorrer: - 90 dias consecutivos sem qualquer sinal de atividade (merged PR, comentário de review, triagem de issue, participação substancial em Discussion ou no Discord), **ou** - 60 dias consecutivos sem responder a qualquer @-mention (solicitação de review de PR, atribuição de issue). Processo: 1. O Core Team faz @-mention do Maintainer em particular no `#maintainers`, dando uma **janela de resposta de 14 dias**. 2. Se não houver resposta substantiva em 14 dias, o Maintainer transita para Emeritus e as permissões são revogadas. 3. Uma nota pública curta e gentil é postada no GitHub Discussions: "Obrigado pelas suas contribuições — você foi movido para Emeritus, é bem-vindo de volta a qualquer momento." 4. Voltar é fácil — veja "Emeritus" abaixo. ### Step-down por justa causa Acionado por: - Comportamento ruim repetido (por exemplo, approvals automáticos em PRs abaixo do padrão, fechamentos maliciosos de issues, abuso de permissões). - Violação do [Código de Conduta][coc] do projeto. - Incidentes de gravidade de segurança (conta comprometida não reportada prontamente, vazamento intencional de roadmap não anunciado, etc.). Processo: 1. Qualquer membro do Core Team pode abrir a discussão. 2. **Pelo menos 3 membros do Core Team** precisam concordar antes de qualquer ação ser tomada (não é exigido o consenso completo do Core Team). 3. Em até 24 horas após a decisão: permissões revogadas, remoção do `#maintainers`, remoção de qualquer roster de Maintainers (**não** transita para Emeritus). 4. A pessoa afetada é informada da decisão e dos motivos, e pode recorrer uma vez. O princípio é **viés a favor de manter o Maintainer**. Um único deslize pequeno não é motivo para step-down forçado; o caminho por justa causa é apenas para padrões repetidos ou incidentes pontuais graves. [coc]: https://www.contributor-covenant.org/ --- ## Emeritus Maintainers que dão step-down de forma voluntária ou transitam por inatividade tornam-se **Emeritus**. O status de Emeritus: - Remove permissões de write/approve/close. - Mantém o nome da pessoa reconhecido na seção Emeritus do roster (interno). - Mantém o acesso ao `#maintainers` no Discord (ler ou postar — escolha do Maintainer). - Não carrega nenhuma responsabilidade contínua. ### Voltando do Emeritus O caminho de retorno mais simples: 3 merged PRs nos 30 dias mais recentes, e então o Core Team restaura as permissões. Não é necessária nova indicação. O ponto do Emeritus é reconhecer que a vida acontece — um sabático, uma mudança de emprego, um filho — sem nenhum drama ou custo social para qualquer das partes. --- ## Mudanças neste documento As regras deste documento podem ser alteradas por consenso do Core Team. Mudanças materiais (critérios de admissão, limiares de step-down) serão anunciadas no GitHub Discussions antes de entrarem em vigor para qualquer candidato ativo. Esclarecimentos editoriais podem ser aplicados diretamente.