mirror of
https://github.com/nexu-io/open-design.git
synced 2026-05-31 19:04:39 +07:00
12ac2e988e
Adds a public set of rules for the External Maintainer role: who qualifies, how nominations work, what permissions Maintainers gain, what's expected of them, and how step-down works. The Core Team's individual roster is intentionally not enumerated. What's public is the rules everyone plays by. - New file: MAINTAINERS.md (English authoritative version) + 5 locale variants matching the existing CONTRIBUTING.md i18n surface (de, fr, ja-JP, pt-BR, zh-CN). Non-EN/non-zh-CN variants are machine-translated drafts marked at the top — native-speaker review is welcome via follow-up PRs. - CONTRIBUTING.md (and its 5 locale variants): adds a short Becoming a Maintainer section that points at MAINTAINERS.md, so the rules live in one place and translation drift is bounded. Decisions not in this PR (intentional): - No internal Core Team roster. - No internal observability dashboards. - No nomination PR / public voting flow (Core-Team-consensus-driven for now; to be revisited once External Maintainers exceed 5). Co-authored-by: Joey Li <lijinwei@open-design.ai>
242 lines
11 KiB
Markdown
242 lines
11 KiB
Markdown
<!-- Machine-translated draft. Native-speaker review and corrections welcome via PR. -->
|
|
# Maintainers
|
|
|
|
<p align="center"><a href="MAINTAINERS.md">English</a> · <b>Português (Brasil)</b> · <a href="MAINTAINERS.de.md">Deutsch</a> · <a href="MAINTAINERS.fr.md">Français</a> · <a href="MAINTAINERS.zh-CN.md">简体中文</a> · <a href="MAINTAINERS.ja-JP.md">日本語</a></p>
|
|
|
|
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.
|