English · Português (Brasil) · Deutsch · Français · 简体中文 · 日本語
+ +Dieses Dokument legt die Regeln dafür fest, wie man Maintainer von `nexu-io/open-design` wird, diese Rolle ausübt und sich aus ihr zurückzieht. Die individuelle Zusammensetzung des Core Teams wird intern verwaltet und ist hier nicht aufgeführt — was öffentlich zählt, sind die Regeln, an die sich alle halten. + +> **Status**: v1, entworfen am 2026-05-11. Begleitdokument zu [`CONTRIBUTING.md`](CONTRIBUTING.md#becoming-a-maintainer) — diese Datei verweist Beitragende für die vollständigen Regeln hierher. + +--- + +## Rollen + +| Rolle | Berechtigungen | +|---|---| +| **Contributor** | Jede Person mit mindestens 1 merged PR. Keine besonderen Berechtigungen. | +| **External Maintainer** | Ein Community-Beitragender, der nach den unten aufgeführten Regeln befördert wurde. Kann Reviews durchführen, approven, issues schließen/wiedereröffnen und sich issues selbst zuweisen. **Kann den merge button nicht klicken** — dies bleibt dem Core Team vorbehalten. | +| **Core Team** | Das interne Team von Open Design. Verfügt über vollen Schreibzugriff auf das Repository und ist die letzte Instanz bei Governance-Entscheidungen. Die Zusammensetzung wird intern verwaltet. | + +Der Rest dieses Dokuments bezieht sich auf **External Maintainers**, sofern nicht anders angegeben. + +--- + +## Was ein Maintainer tun kann, was ein Contributor nicht kann + +| Aktion | Contributor | Maintainer | +|---|:---:|:---:| +| Einen PR approven | ⚠️ zählt als Kommentar, **nicht** als die erforderliche Approval | ✓ zählt als die erforderliche Approval für den Merge | +| Issues schließen / wiedereröffnen | Nur issues, die sie selbst geöffnet haben | ✓ jedes issue | +| Sich offene, nicht zugewiesene issues selbst zuweisen (P0 zuerst) | ✗ | ✓ | + +### Merge-Anforderungen + +Jeder PR — unabhängig davon, wer ihn verfasst hat — benötigt **alle drei** der folgenden Punkte: + +1. Keine Code-Konflikte. +2. CI vollständig grün. +3. Mindestens eine Approval von einem Maintainer oder einem Core-Team-Mitglied. + +Die Approval eines Maintainers ist der Weg, den die meisten PRs zum Merge nehmen — sie ist die direkteste Art, wie sich das Vertrauen eines Maintainers im täglichen Projektgeschehen zeigt. + +--- + +## Wie man Maintainer wird + +Es gibt **drei** Aufnahmekriterien. Alle drei müssen erfüllt sein. + +### 1. Beitragsumfang + +- **≥ 20 merged PRs** zu `nexu-io/open-design`. + +Dies ist eine weiche Untergrenze, kein automatisches Ticket. Das Erreichen von 20 PRs bringt Sie in die Betrachtung; es garantiert die Rolle nicht. + +### 2. Account-Qualität (Anti-Sock-Puppet, Anti-Bot) + +Wir prüfen das GitHub-Profil des Kandidaten anhand von sieben Dimensionen. **Mindestens 5 von 7 Aufnahmelinien müssen erfüllt sein, und null Veto-Linien dürfen ausgelöst werden.** + +| # | Dimension | Aufnahmelinie | Veto-Linie | +|---|---|---|---| +| 1 | Alter des GitHub-Accounts | ≥ 1 Jahr | < 90 Tage | +| 2 | Öffentliche Repos | ≥ 3 | 0 | +| 3 | Follower | ≥ 10 | < 3 | +| 4 | Verhältnis Follower / Following | > 0,30 | < 0,05 (typisches Follow-Farm-Muster) | +| 5 | Profilvollständigkeit | Eigener Avatar **und** mindestens eines von bio / company / blog / twitter | Standard-Avatar **und** alle von bio/company/blog leer | +| 6 | Projektübergreifende Aktivität | Mindestens ein merged PR oder anhaltende issue-/Star-Aktivität in **einem anderen** öffentlichen Repo | Merged PRs nur in diesem Repo | +| 7 | Account-Status | Keine Plattform-Beschränkungen auf GitHub (spam/banned/restored) | Eines der oben genannten | + +#### Frühphasen-Ausnahme (läuft automatisch ab, wenn das Repo 6 Monate alt wird) + +Solange `nexu-io/open-design` jünger als sechs Monate seit dem initialen Commit ist, kann das Veto zur **projektübergreifenden Aktivität** (#6) durch Konsens des Core Teams ausgesetzt werden, wenn: + +- Die Dimensionen 1, 2, 3 und 5 deutlich über der Aufnahmelinie liegen; **und** +- Die PR-Qualität des Kandidaten in diesem Repo vom Core Team nach praxisnaher Prüfung als hoch beurteilt wird. + +Eine solche Ausnahme muss in der internen Aufzeichnung des Core Teams zusammen mit dem Namen des Kandidaten und dem Datum vermerkt werden. Sobald das Repo sechs Monate alt ist, steht diese Ausnahmeklausel nicht mehr zur Verfügung. + +### 3. Beitragsqualität (Beurteilung durch das Core Team) + +Dies ist qualitativ und nicht formelbasiert. Das Core Team betrachtet: + +- **Code-Qualität** der merged PRs (Korrektheit, Disziplin im Umfang, Respekt vor Repo-Grenzen). +- **Review-Qualität** etwaiger Review-Kommentare zu PRs anderer. +- **Community-Beteiligung** — Discussions, issue-Triage, Engagement auf Discord. +- **Kollaborations-Signale** — Reaktionsbereitschaft auf Feedback, Bereitschaft zur Überarbeitung. + +Das Bestehen der ersten beiden Kriterien bringt Sie in den Kandidatenpool. Das Überschreiten dieser dritten Schwelle führt zur Nominierung. + +### Auswahlprozess + +1. Ein Core-Team-Mitglied bringt den Kandidaten intern zur Sprache. +2. Das Core Team erzielt einen Konsens. +3. Ein Core-Team-Mitglied nimmt privat Kontakt auf, um die Bereitschaft des Kandidaten zu bestätigen. +4. Onboarding. +5. Öffentliche Bekanntmachung. + +Es gibt keinen Nominierungs-PR, keine öffentliche Abstimmung, keine feste Amtszeit. Die Absicht ist das **Gegenteil des K8s-/Apache-Approver-Vote-Modells** — in der frühen Lebensphase des Projekts ist ein leichtgewichtiger Konsens des Core Teams schneller und führt zu einem Ergebnis gleicher Qualität. Sobald die Maintainer-Gruppe über fünf External Maintainers hinauswächst, wird dieser Abschnitt überarbeitet. + +--- + +## Verantwortlichkeiten und Erwartungen + +**Es gibt keine festen Quoten.** Keine wöchentliche PR-Review-Zahl, keine Mindestrate für issue-Triage, kein SLA für Antwortzeiten. Die Maintainer-Rolle ist eine Anerkennung von Vertrauen, kein unbezahlter Job. + +Was wir im Geiste erwarten: + +- Approven Sie PRs, für die Sie den Kontext haben; enthalten Sie sich, wenn nicht. +- Halten Sie sich an die Merge-Anforderungen (§ „Merge-Anforderungen") — Ihre Approval ist ein echtes Signal, kein Stempel. +- Halten Sie `#maintainers` informiert, wenn Sie über einen längeren Zeitraum nicht erreichbar sein werden. +- Behandeln Sie die noch nicht öffentliche Roadmap, die in `#maintainers` geteilt wird, als vertraulich. + +Wenn das Core Team ein Muster von Fehlverhalten beobachtet (Rubber-Stamp-Approvals, böswilliges Schließen von issues, Weitergabe nicht angekündigter Roadmap-Inhalte usw.), werden die Berechtigungen gemäß § „Rücktritt — aus wichtigem Grund" entzogen. + +--- + +## Maintainer-exklusiver Zugang + +Über die oben aufgeführten Repository-Berechtigungen hinaus erhalten Maintainer einige Dinge, die der breiteren Community nicht zur Verfügung stehen: + +- **Discord-Channel `#maintainers`** — ein privater Arbeitsbereich, der gemeinsam mit dem Core Team genutzt wird. Verwendet für Design-Vorschauen, RFC-Entwürfe und interne Koordination zum noch nicht öffentlichen Teil der Roadmap. +- **Vertrauliche Roadmap** — frühe Einsicht in Arbeiten, die noch nicht angekündigt wurden. Maintainer verpflichten sich, deren Inhalte vertraulich zu behandeln, bis ein Core-Team-Mitglied sie öffentlich ankündigt. +- **Direkter Draht zum Core Team** — Ihre Nachrichten in `#maintainers` erhalten eine schnellere und substantiellere Antwort als öffentliche Discussions, und das Core Team holt aktiv Maintainer-Input zu Architektur- und Roadmap-Entscheidungen ein. +- **Maintainer-Badge** — eine öffentliche Vertrauensauszeichnung auf Ihrem GitHub-Profil und in MAINTAINERS-bezogenen Repo-Bereichen (wird ausgerollt, sobald die GitHub-Badge-Funktionalität verfügbar ist). +- **Öffentliche Anerkennung bei der Beförderung** — Ankündigung auf Twitter, GitHub Discussions und Discord, wenn Sie beitreten. + +--- + +## Rücktritt + +Die Maintainer-Rolle ist keine lebenslange Ernennung. Es gibt drei Wege des Ausscheidens. + +### Geordneter Rücktritt (freiwillig) + +- Der Maintainer schreibt das Core Team an oder postet in `#maintainers`. +- Die Berechtigungen werden innerhalb von 24 Stunden entzogen. +- Der Maintainer wechselt in den **Emeritus**-Status. +- Eine öffentliche Begründung ist nicht erforderlich. + +### Inaktivitäts-Übergang + +Ein Maintainer wird für den Inaktivitäts-Übergang in Betracht gezogen, wenn **eines** der folgenden Kriterien zutrifft: + +- 90 aufeinanderfolgende Tage ohne Aktivitätssignal (merged PR, Review-Kommentar, issue-Triage, substantielle Beteiligung in Discussions oder Discord), **oder** +- 60 aufeinanderfolgende Tage ohne Reaktion auf eine @-Erwähnung (PR-Review-Anfrage, issue-Zuweisung). + +Ablauf: + +1. Das Core Team @-erwähnt den Maintainer privat in `#maintainers` und gewährt ein **14-tägiges Antwortfenster**. +2. Erfolgt innerhalb von 14 Tagen keine substantielle Antwort, wechselt der Maintainer in den Emeritus-Status, und die Berechtigungen werden entzogen. +3. Eine kurze, freundliche öffentliche Notiz wird in GitHub Discussions gepostet: „Vielen Dank für Ihre Beiträge — Sie wurden in den Emeritus-Status überführt, Sie sind jederzeit wieder willkommen." +4. Die Rückkehr ist einfach — siehe „Emeritus" weiter unten. + +### Rücktritt aus wichtigem Grund + +Ausgelöst durch: + +- Wiederholtes Fehlverhalten (z. B. Rubber-Stamp-Approvals bei minderwertigen PRs, böswilliges Schließen von issues, Missbrauch von Berechtigungen). +- Verstoß gegen den [Verhaltenskodex][coc] des Projekts. +- Sicherheitsrelevante Vorfälle (kompromittierter Account, der nicht umgehend gemeldet wurde, vorsätzliches Leaken nicht angekündigter Roadmap-Inhalte usw.). + +Ablauf: + +1. Jedes Core-Team-Mitglied kann die Diskussion eröffnen. +2. **Mindestens 3 Core-Team-Mitglieder** müssen zustimmen, bevor Maßnahmen ergriffen werden (ein vollständiger Core-Team-Konsens ist nicht erforderlich). +3. Innerhalb von 24 Stunden nach der Entscheidung: Berechtigungen entzogen, Entfernung aus `#maintainers`, Entfernung von allen Maintainer-Listen (es erfolgt **kein** Übergang in den Emeritus-Status). +4. Die betroffene Person wird über die Entscheidung und die Gründe informiert und kann einmal Einspruch einlegen. + +Das Prinzip lautet **im Zweifel für den Verbleib des Maintainers**. Ein einzelner kleiner Ausrutscher ist kein Grund für einen erzwungenen Rücktritt; der Weg „aus wichtigem Grund" ist ausschließlich für wiederholte Muster oder schwere Einzelvorfälle vorgesehen. + +[coc]: https://www.contributor-covenant.org/ + +--- + +## Emeritus + +Maintainer, die geordnet zurücktreten oder durch Inaktivität übergehen, werden zu **Emeritus**. Der Emeritus-Status: + +- Entzieht Schreib-/Approve-/Close-Berechtigungen. +- Behält die namentliche Anerkennung der Person im Emeritus-Bereich der (internen) Liste bei. +- Behält den Zugang zum Discord-Channel `#maintainers` (lesend oder schreibend — nach Wahl des Maintainers). +- Bringt keine fortlaufende Verantwortung mit sich. + +### Rückkehr aus dem Emeritus-Status + +Der einfachste Rückkehrweg: 3 merged PRs in den letzten 30 Tagen, dann stellt das Core Team die Berechtigungen wieder her. Eine erneute Nominierung ist nicht erforderlich. + +Der Sinn des Emeritus-Status besteht darin, anzuerkennen, dass das Leben passiert — ein Sabbatical, ein Jobwechsel, ein Kind — ohne Drama und ohne sozialen Preis auf beiden Seiten. + +--- + +## Änderungen an diesem Dokument + +Die Regeln in diesem Dokument können durch Konsens des Core Teams geändert werden. Wesentliche Änderungen (Aufnahmekriterien, Rücktritts-Schwellenwerte) werden in GitHub Discussions angekündigt, bevor sie für aktive Kandidaten in Kraft treten. Redaktionelle Klarstellungen können direkt übernommen werden. diff --git a/MAINTAINERS.fr.md b/MAINTAINERS.fr.md new file mode 100644 index 000000000..b0d0b7b1a --- /dev/null +++ b/MAINTAINERS.fr.md @@ -0,0 +1,192 @@ + +# Mainteneurs + +English · Português (Brasil) · Deutsch · Français · 简体中文 · 日本語
+ +Ce document définit les règles pour devenir Maintainer de `nexu-io/open-design`, exercer ce rôle et y renoncer. La liste nominative du Core Team est tenue en interne et n'est pas énumérée ici — ce qui compte publiquement, ce sont les règles que tout le monde respecte. + +> **Statut** : v1, rédigé le 2026-05-11. Document complémentaire à [`CONTRIBUTING.md`](CONTRIBUTING.md#becoming-a-maintainer) — ce fichier renvoie les contributeurs ici pour les règles complètes. + +--- + +## Rôles + +| Rôle | Permissions | +|---|---| +| **Contributor** | Toute personne ayant au moins 1 merged PR. Aucune permission spéciale. | +| **External Maintainer** | Un contributeur de la communauté promu selon les règles ci-dessous. Peut faire des reviews, approve, fermer/rouvrir des issues, et s'auto-assigner des issues. **Ne peut pas cliquer sur le merge button** — cela reste réservé au Core Team. | +| **Core Team** | L'équipe interne d'Open Design. Détient un accès en écriture complet sur le repository et constitue l'autorité finale sur les décisions de gouvernance. La liste est tenue en interne. | + +Le reste de ce document concerne les **External Maintainers** sauf indication contraire. + +--- + +## Ce qu'un Maintainer peut faire et qu'un Contributor ne peut pas + +| Action | Contributor | Maintainer | +|---|:---:|:---:| +| Approve une PR | ⚠️ compte comme un commentaire, **et non** comme l'approbation requise | ✓ compte comme l'approbation requise pour le merge | +| Fermer / rouvrir des issues | Uniquement les issues qu'ils ont eux-mêmes ouvertes | ✓ toute issue | +| S'auto-assigner des issues ouvertes et non assignées (P0 en priorité) | ✗ | ✓ | + +### Conditions de merge + +Toute PR — quel que soit son auteur — nécessite **les trois** éléments suivants : + +1. Aucun conflit de code. +2. CI entièrement au vert. +3. Au moins une approbation d'un Maintainer ou d'un membre du Core Team. + +L'approbation d'un Maintainer est la voie empruntée par la plupart des PR pour être mergées — c'est la manière la plus directe dont la confiance d'un Maintainer se manifeste dans le quotidien du projet. + +--- + +## Comment devenir Maintainer + +Il existe **trois** critères d'entrée. Tous les trois doivent être remplis. + +### 1. Volume de contributions + +- **≥ 20 merged PRs** sur `nexu-io/open-design`. + +Il s'agit d'un seuil minimal indicatif, et non d'un sésame automatique. Atteindre 20 PRs vous met dans la liste des candidats à examiner ; cela ne garantit pas le rôle. + +### 2. Qualité du compte (anti-sock-puppet, anti-bot) + +Nous évaluons le profil GitHub du candidat selon sept dimensions. **Il faut passer au moins 5 des 7 lignes d'admission, et ne déclencher aucune ligne de veto.** + +| # | Dimension | Ligne d'admission | Ligne de veto | +|---|---|---|---| +| 1 | Ancienneté du compte GitHub | ≥ 1 an | < 90 jours | +| 2 | Repos publics | ≥ 3 | 0 | +| 3 | Followers | ≥ 10 | < 3 | +| 4 | Ratio followers / following | > 0,30 | < 0,05 (schéma typique de follow-farm) | +| 5 | Complétude du profil | Avatar personnalisé **et** au moins l'un des éléments suivants : bio / company / blog / twitter | Avatar par défaut **et** bio/company/blog tous vides | +| 6 | Activité inter-projets | Au moins une merged PR ou une activité soutenue (issues/stars) sur **un autre** repo public | Merged PRs uniquement sur ce repo | +| 7 | Statut du compte | Aucune restriction de la plateforme GitHub (spam/banni/restauré) | L'un quelconque des cas ci-dessus | + +#### Dérogation projet jeune (expire automatiquement quand le repo atteint 6 mois) + +Tant que `nexu-io/open-design` a moins de six mois depuis le commit initial, le veto sur l'**activité inter-projets** (#6) peut faire l'objet d'une dérogation par consensus du Core Team lorsque : + +- Les dimensions 1, 2, 3 et 5 sont nettement au-dessus de la ligne d'admission ; **et** +- La qualité des PRs du candidat sur ce repo est jugée élevée par la review pratique du Core Team. + +Toute dérogation doit être consignée dans le registre interne du Core Team avec le nom du candidat et la date. Une fois que le repo atteint six mois, cette clause de dérogation n'est plus disponible. + +### 3. Qualité des contributions (jugement du Core Team) + +Ce critère est qualitatif et non basé sur une formule. Le Core Team examine : + +- **La qualité du code** des merged PRs (correction, discipline de portée, respect des frontières du repo). +- **La qualité des reviews** dans les commentaires de review laissés sur les PRs des autres. +- **La participation à la communauté** — Discussions, triage d'issues, engagement sur Discord. +- **Les signaux de collaboration** — réactivité aux retours, volonté de réviser. + +Passer les deux premiers critères vous fait entrer dans le pool de candidats. Franchir ce troisième seuil est ce qui vous fait nommer. + +### Processus de sélection + +1. Un membre du Core Team présente le candidat en interne. +2. Le Core Team parvient à un consensus. +3. Un membre du Core Team prend contact en privé pour confirmer que le candidat est volontaire. +4. Onboarding. +5. Annonce publique. + +Il n'y a pas de PR de nomination, pas de vote public, pas de mandat à durée fixe. L'intention est l'**inverse du modèle approver-vote de K8s/Apache** — au début de la vie du projet, un consensus léger du Core Team va plus vite et produit la même qualité de résultat. Lorsque la cohorte de Maintainers dépassera cinq External Maintainers, cette section sera réexaminée. + +--- + +## Responsabilités et attentes + +**Il n'y a pas de quotas stricts.** Pas de nombre hebdomadaire de reviews de PR, pas de taux minimal de triage d'issues, pas de SLA sur les délais de réponse. Être Maintainer est une reconnaissance de confiance, pas un emploi non rémunéré. + +Ce que nous demandons, dans l'esprit : + +- Approve les PRs pour lesquelles vous avez le contexte ; abstenez-vous quand ce n'est pas le cas. +- Honorez les conditions de merge (§ « Conditions de merge ») — votre approbation est un signal réel, pas un tampon de complaisance. +- Tenez `#maintainers` informé si vous comptez disparaître pour une période prolongée. +- Traitez la roadmap encore non publique partagée dans `#maintainers` comme confidentielle. + +Si le Core Team observe un schéma de comportement problématique (approbations de complaisance, fermetures malveillantes d'issues, fuite d'éléments de roadmap non annoncés, etc.), les permissions sont révoquées au titre du § « Step-down — pour motif valable ». + +--- + +## Accès réservé aux Maintainers + +Au-delà des permissions de repository listées ci-dessus, les Maintainers reçoivent quelques avantages que la communauté plus large n'a pas : + +- **Canal Discord `#maintainers`** — un espace de travail privé partagé avec le Core Team. Utilisé pour les previews de design, les drafts de RFC et la coordination interne sur la partie non encore publique de la roadmap. +- **Roadmap confidentielle** — visibilité anticipée sur des travaux qui n'ont pas encore été annoncés. Les Maintainers s'engagent à traiter ce contenu comme confidentiel jusqu'à ce qu'un membre du Core Team l'annonce publiquement. +- **Ligne directe avec le Core Team** — vos messages dans `#maintainers` reçoivent une réponse plus rapide et plus substantielle que les Discussions publiques, et le Core Team sollicite réellement l'avis des Maintainers sur les décisions d'architecture et de roadmap. +- **Badge Maintainer** — une marque publique de confiance sur votre profil GitHub et sur les surfaces du repo liées aux MAINTAINERS (déploiement progressif une fois la fonctionnalité de badge GitHub en place). +- **Reconnaissance publique lors de la promotion** — annonce sur Twitter, dans les GitHub Discussions et sur Discord lors de votre arrivée. + +--- + +## Step-down + +Être Maintainer n'est pas une nomination à vie. Il existe trois voies de sortie. + +### Step-down volontaire + +- Le Maintainer envoie un message au Core Team ou poste dans `#maintainers`. +- Les permissions sont révoquées dans les 24 heures. +- Le Maintainer passe au statut **Emeritus**. +- Aucune justification publique n'est requise. + +### Transition pour inactivité + +Un Maintainer est éligible à une transition pour inactivité lorsque **l'un** des cas suivants se produit : + +- 90 jours consécutifs sans signal d'activité (merged PR, commentaire de review, triage d'issue, participation substantielle aux Discussions ou à Discord), **ou** +- 60 jours consécutifs sans répondre à aucune @-mention (demande de review de PR, assignation d'issue). + +Processus : + +1. Le Core Team @-mentionne le Maintainer en privé dans `#maintainers`, en accordant une **fenêtre de réponse de 14 jours**. +2. En l'absence de réponse substantielle sous 14 jours, le Maintainer passe au statut Emeritus et ses permissions sont révoquées. +3. Une note publique brève et bienveillante est postée dans les GitHub Discussions : « Merci pour vos contributions — vous avez été placé en Emeritus, vous êtes le bienvenu pour revenir à tout moment. » +4. Le retour est facile — voir « Emeritus » ci-dessous. + +### Step-down pour motif valable + +Déclenché par : + +- Comportement problématique répété (par ex., approbations de complaisance sur des PRs en deçà des standards, fermetures malveillantes d'issues, abus de permissions). +- Violation du [Code de Conduite][coc] du projet. +- Incidents de niveau sécurité (compte compromis non signalé rapidement, fuite intentionnelle d'éléments de roadmap non annoncés, etc.). + +Processus : + +1. Tout membre du Core Team peut ouvrir la discussion. +2. **Au moins 3 membres du Core Team** doivent être d'accord avant qu'une action soit prise (le consensus complet du Core Team n'est pas requis). +3. Dans les 24 heures suivant la décision : permissions révoquées, retrait de `#maintainers`, retrait de toute liste de Maintainers (ne passe **pas** au statut Emeritus). +4. La personne concernée est informée de la décision et de ses motifs, et peut faire appel une fois. + +Le principe est de **pencher en faveur du maintien du Maintainer**. Un seul petit écart ne constitue pas un motif de step-down forcé ; la voie pour motif valable est réservée aux schémas répétés ou aux incidents ponctuels graves. + +[coc]: https://www.contributor-covenant.org/ + +--- + +## Emeritus + +Les Maintainers qui se retirent volontairement ou qui transitent par inactivité passent au statut **Emeritus**. Le statut Emeritus : + +- Retire les permissions d'écriture/approve/fermeture. +- Conserve la mention du nom de la personne dans la section Emeritus de la liste (interne). +- Conserve l'accès au canal Discord `#maintainers` (en lecture ou en écriture — au choix du Maintainer). +- N'implique aucune responsabilité continue. + +### Revenir depuis Emeritus + +La voie de retour la plus simple : 3 merged PRs au cours des 30 derniers jours, après quoi le Core Team restaure les permissions. Aucune nouvelle nomination n'est requise. + +L'objectif d'Emeritus est de reconnaître que la vie suit son cours — un congé sabbatique, un changement d'emploi, un enfant — sans aucun drame ni coût social pour aucune des parties. + +--- + +## Modifications de ce document + +Les règles de ce document peuvent être amendées par consensus du Core Team. Les changements substantiels (critères d'admission, seuils de step-down) seront annoncés dans les GitHub Discussions avant de prendre effet pour tout candidat actif. Les clarifications éditoriales peuvent être intégrées directement. diff --git a/MAINTAINERS.ja-JP.md b/MAINTAINERS.ja-JP.md new file mode 100644 index 000000000..4729d0c84 --- /dev/null +++ b/MAINTAINERS.ja-JP.md @@ -0,0 +1,192 @@ + +# Maintainers + +English · Português (Brasil) · Deutsch · Français · 简体中文 · 日本語
+ +このドキュメントは、`nexu-io/open-design` の Maintainer になるため、その役割を務めるため、そして退任するためのルールを定めるものです。Core Team の個別のメンバー一覧は内部で管理されており、ここには列挙していません。公に重要なのは、全員が従うルールそのものです。 + +> **ステータス**: v1、2026-05-11 にドラフト作成。[`CONTRIBUTING.md`](CONTRIBUTING.md#becoming-a-maintainer) のコンパニオン文書です。CONTRIBUTING.md は、コントリビューターを完全なルールのためにこちらへ案内しています。 + +--- + +## 役割 + +| 役割 | 権限 | +|---|---| +| **Contributor** | 1 件以上の merged PR を持つすべての人。特別な権限はありません。 | +| **External Maintainer** | 後述のルールにより昇格したコミュニティのコントリビューター。レビュー、approve、issue のクローズ/リオープン、issue の自己アサインが可能です。**merge button をクリックすることはできません** — それは Core Team に留まります。 | +| **Core Team** | Open Design の内部チーム。リポジトリへのフルライト権限を持ち、ガバナンス上の決定における最終権限を有します。メンバー一覧は内部で管理されています。 | + +特に断りのない限り、本ドキュメントの残りの部分は **External Maintainer** に関するものです。 + +--- + +## Contributor にはできず Maintainer にできること + +| アクション | Contributor | Maintainer | +|---|:---:|:---:| +| PR を approve する | ⚠️ コメント扱いとなり、必要な承認には**カウントされません** | ✓ merge に必要な承認としてカウントされます | +| issue のクローズ / リオープン | 自分が開いた issue のみ | ✓ 任意の issue | +| オープンかつ未アサインの issue を自己アサイン（P0 を優先） | ✗ | ✓ | + +### Merge の要件 + +PR は — 誰が作成したものであれ — 以下の **3 つすべて** が必要です： + +1. コードコンフリクトがないこと。 +2. CI が完全にグリーンであること。 +3. Maintainer または Core Team メンバーから少なくとも 1 件の承認があること。 + +ほとんどの PR は Maintainer の承認を経て merge されます。これは、Maintainer の信頼がプロジェクトの日々の運営に最も直接的に表れる形です。 + +--- + +## Maintainer になる方法 + +参入条件は **3 つ** あります。3 つすべてを満たす必要があります。 + +### 1. 貢献量 + +- `nexu-io/open-design` への **20 件以上の merged PR**。 + +これはあくまでソフトな下限であり、自動的なチケットではありません。20 PR に到達することで検討対象に入りますが、役割が保証されるわけではありません。 + +### 2. アカウントの品質（ソックパペット対策・ボット対策） + +候補者の GitHub プロフィールを 7 つの観点で確認します。**7 項目中少なくとも 5 つの admission line をパスし、かつ veto line を 1 つもトリガーしないこと。** + +| # | 観点 | Admission line | Veto line | +|---|---|---|---| +| 1 | GitHub アカウントの年齢 | 1 年以上 | 90 日未満 | +| 2 | パブリックリポジトリ数 | 3 以上 | 0 | +| 3 | フォロワー数 | 10 以上 | 3 未満 | +| 4 | フォロワー / フォロー比率 | 0.30 超 | 0.05 未満（典型的なフォローファームのパターン） | +| 5 | プロフィールの完成度 | カスタムアバター **かつ** bio / company / blog / twitter のうち少なくとも 1 つ | デフォルトアバター **かつ** bio/company/blog がすべて空 | +| 6 | クロスプロジェクト活動 | **別の** パブリックリポジトリで少なくとも 1 件の merged PR、または継続的な issue/star 活動 | merged PR が当リポジトリのみ | +| 7 | アカウントの状態 | GitHub プラットフォームによる制限なし（spam/banned/restored） | 上記のいずれかに該当 | + +#### 初期プロジェクトの猶予条項（リポジトリが 6 ヶ月を迎えた時点で自動失効） + +`nexu-io/open-design` が初回コミットから 6 ヶ月未満である間は、以下の場合に **クロスプロジェクト活動** の veto（#6）を Core Team の合意により免除できます： + +- 観点 1、2、3、5 が admission line を明確に上回っていること。**かつ** +- 当リポジトリにおける候補者の PR 品質が、Core Team の実地レビューにより高いと判断されること。 + +免除は、候補者の名前と日付とともに Core Team の内部記録に記載しなければなりません。リポジトリが 6 ヶ月に達した後は、この猶予条項は利用できなくなります。 + +### 3. 貢献の品質（Core Team の判断） + +これは定性的なものであり、公式に基づくものではありません。Core Team は以下を見ます： + +- merged PR の **コード品質**（正確さ、スコープの規律、リポジトリ境界の尊重）。 +- 他者の PR に残されたレビューコメントの **レビュー品質**。 +- **コミュニティへの参加** — Discussions、issue トリアージ、Discord での関与。 +- **協働のシグナル** — フィードバックへの応答性、修正への意欲。 + +最初の 2 つの基準を満たすことで候補者プールに入ります。この 3 つ目の閾値を超えることが、推薦されるための条件です。 + +### 選考プロセス + +1. Core Team メンバーが内部で候補者を提起します。 +2. Core Team が合意に至ります。 +3. Core Team メンバーが非公開で本人に連絡し、意思を確認します。 +4. オンボーディング。 +5. 公開アナウンス。 + +推薦 PR も公開投票も固定任期もありません。意図しているのは、**K8s/Apache 方式の approver 投票モデルの逆**です — プロジェクトの初期段階では、軽量な Core Team の合意の方が早く動き、同じ品質の結果を生み出します。External Maintainer のコホートが 5 名を超えて成長した時点で、このセクションは見直されます。 + +--- + +## 責任と期待 + +**ハードなノルマはありません。** 週単位の PR レビュー件数も、最低限の issue トリアージ率も、応答時間の SLA もありません。Maintainership は信頼の認知であり、無償の仕事ではありません。 + +精神としてお願いしたいことは： + +- 文脈を理解している PR を approve すること。理解していないときは保留すること。 +- merge 要件（§「Merge の要件」）を尊重すること — あなたの承認は実際のシグナルであり、形式的な押印ではありません。 +- 長期間活動から離れる場合は `#maintainers` に知らせておくこと。 +- `#maintainers` で共有される未公開のロードマップは機密として扱うこと。 + +Core Team が悪いケースの行動パターン（形式的な承認、悪意ある issue クローズ、未公開ロードマップの漏洩など）を観察した場合、§「Step-down — 理由ありの場合」に基づき権限が剥奪されます。 + +--- + +## Maintainer 限定のアクセス + +上記のリポジトリ権限に加えて、Maintainer は広いコミュニティが得られないものをいくつか受け取ります： + +- **Discord `#maintainers` チャンネル** — Core Team と共有されるプライベートな作業スペースです。デザインプレビュー、RFC ドラフト、未公開のロードマップに関する内部調整に使用されます。 +- **機密ロードマップ** — まだアナウンスされていない作業への早期可視性。Maintainer は、Core Team メンバーが公にアナウンスするまで、その内容を機密として扱うことに同意します。 +- **Core Team への直通ライン** — `#maintainers` のメッセージは、公開 Discussions よりも迅速かつ実質的な応答を得られます。Core Team は、アーキテクチャやロードマップの決定について、Maintainer の意見を真摯に求めます。 +- **Maintainer バッジ** — GitHub プロフィールおよび MAINTAINERS 関連のリポジトリ表面に表示される、公的な信頼の印（GitHub のバッジ機能が整い次第展開）。 +- **昇格時の公開的な顕彰** — 加入時に Twitter、GitHub Discussions、Discord でアナウンスされます。 + +--- + +## Step-down + +Maintainership は終身任用ではありません。3 つの退出経路があります。 + +### グレースフルな退任（自発的） + +- Maintainer が Core Team にメッセージを送るか、`#maintainers` に投稿します。 +- 24 時間以内に権限が剥奪されます。 +- Maintainer は **Emeritus** ステータスへ移行します。 +- 公の理由は不要です。 + +### 非アクティブによる移行 + +以下の **いずれか** に該当する場合、Maintainer は非アクティブ移行の対象として検討されます： + +- 90 日連続でアクティビティのシグナルがない（merged PR、レビューコメント、issue トリアージ、Discussion または Discord での実質的な参加）、**または** +- 60 日連続で @-mention（PR レビューリクエスト、issue アサイン）に応答していない。 + +プロセス： + +1. Core Team が `#maintainers` で非公開に Maintainer を @-mention し、**14 日間の応答期間** を与えます。 +2. 14 日以内に実質的な応答がない場合、Maintainer は Emeritus へ移行し、権限が剥奪されます。 +3. GitHub Discussions に、短くて温かい公開ノートを投稿します：「貢献ありがとうございました — Emeritus に移行されました。いつでも戻ってきてください。」 +4. 戻るのは簡単です — 下記「Emeritus」を参照してください。 + +### 理由ありの Step-down + +トリガーとなるもの： + +- 悪いケースの行動の繰り返し（例：基準を満たさない PR への形式的承認、悪意ある issue クローズ、権限の濫用）。 +- プロジェクトの[行動規範][coc]違反。 +- セキュリティ等級のインシデント（侵害されたアカウントの速やかな報告がない、未公開ロードマップの意図的な漏洩など）。 + +プロセス： + +1. 任意の Core Team メンバーが議論を開始できます。 +2. アクションを取る前に **少なくとも 3 名の Core Team メンバー** の同意が必要です（Core Team 全員の合意は必要ありません）。 +3. 決定から 24 時間以内に：権限の剥奪、`#maintainers` からの除外、Maintainer ロスターからの削除（Emeritus へは移行**しません**）。 +4. 影響を受けた本人には決定と理由が通知され、1 度だけ異議申し立てが可能です。 + +原則は **Maintainer を残す方向にバイアスをかける** ことです。1 度の小さな失敗は強制退任の理由にはなりません。理由ありの経路は、繰り返されるパターン、または重大な単発インシデントのみを対象とします。 + +[coc]: https://www.contributor-covenant.org/ + +--- + +## Emeritus + +グレースフルに退任した、または非アクティブ経由で移行した Maintainer は **Emeritus** となります。Emeritus ステータスは： + +- write/approve/close 権限を削除します。 +- （内部）ロスターの Emeritus セクションに本人の名前を残します。 +- Discord `#maintainers` へのアクセスを維持します（読み取りまたは投稿 — Maintainer の選択）。 +- 継続的な責任は伴いません。 + +### Emeritus からの復帰 + +最もシンプルな復帰経路：直近 30 日以内に 3 件の merged PR を達成すれば、Core Team が権限を復元します。再推薦は不要です。 + +Emeritus の趣旨は、人生には色々あるということを認めることです — サバティカル、転職、子育てなど — どちら側にもドラマや社会的コストを生じさせることなく。 + +--- + +## このドキュメントの変更について + +本ドキュメントのルールは、Core Team の合意により改定可能です。実質的な変更（参入基準、退任しきい値）は、いかなる現役候補者にも適用される前に GitHub Discussions でアナウンスされます。編集上の明確化は直接反映できます。 diff --git a/MAINTAINERS.md b/MAINTAINERS.md new file mode 100644 index 000000000..1c75c5e9d --- /dev/null +++ b/MAINTAINERS.md @@ -0,0 +1,243 @@ +# Maintainers + +English · Português (Brasil) · Deutsch · Français · 简体中文 · 日本語
+ +This document defines the rules for becoming, serving as, and stepping down from +a Maintainer of `nexu-io/open-design`. The Core Team's individual roster is +maintained internally and is not enumerated here — what matters publicly are +the rules everyone plays by. + +> **Status**: v1, drafted 2026-05-11. Companion to [`CONTRIBUTING.md`](CONTRIBUTING.md#becoming-a-maintainer) — that file points contributors here for the full rules. + +--- + +## Roles + +| Role | Permissions | +|---|---| +| **Contributor** | Anyone with at least 1 merged PR. No special permissions. | +| **External Maintainer** | A community contributor promoted under the rules below. Can review, approve, close/reopen issues, and self-assign issues. **Cannot click the merge button** — that stays with the Core Team. | +| **Core Team** | Open Design's internal team. Holds full repository write access and is the final authority on governance decisions. Roster maintained internally. | + +The rest of this document is about **External Maintainers** unless stated otherwise. + +--- + +## What a Maintainer can do that a Contributor cannot + +| Action | Contributor | Maintainer | +|---|:---:|:---:| +| Approve a PR | ⚠️ counts as a comment, **not** as the required approval | ✓ counts as the required approval for merge | +| Close / reopen issues | Only issues they opened themselves | ✓ any issue | +| Self-assign open, unassigned issues (P0 first) | ✗ | ✓ | + +### Merge requirements + +Any PR — regardless of who authored it — needs **all three** of: + +1. No code conflicts. +2. CI fully green. +3. At least one approval from a Maintainer or Core Team member. + +A Maintainer's approval is the path most PRs take to merge — it's the most direct way a Maintainer's trust shows up in the project's day-to-day. + +--- + +## How to become a Maintainer + +There are **three** entry criteria. All three must be met. + +### 1. Contribution volume + +- **≥ 20 merged PRs** to `nexu-io/open-design`. + +This is a soft floor, not an automatic ticket. Hitting 20 PRs gets you into +consideration; it does not guarantee the role. + +### 2. Account quality (anti-sock-puppet, anti-bot) + +We check the candidate's GitHub profile against seven dimensions. **Pass at +least 5 of 7 admission lines, and trigger zero veto lines.** + +| # | Dimension | Admission line | Veto line | +|---|---|---|---| +| 1 | GitHub account age | ≥ 1 year | < 90 days | +| 2 | Public repos | ≥ 3 | 0 | +| 3 | Followers | ≥ 10 | < 3 | +| 4 | Followers / following ratio | > 0.30 | < 0.05 (typical follow-farm pattern) | +| 5 | Profile completeness | Custom avatar **and** at least one of bio / company / blog / twitter | Default avatar **and** all of bio/company/blog empty | +| 6 | Cross-project activity | At least one merged PR or sustained issue/star activity in **another** public repo | Merged PRs only in this repo | +| 7 | Account standing | No GitHub platform restrictions (spam/banned/restored) | Any of the above | + +#### Early-project waiver (auto-expires when repo turns 6 months old) + +While `nexu-io/open-design` is younger than six months from initial commit, +the **cross-project activity** veto (#6) may be waived by Core Team consensus +when: + +- Dimensions 1, 2, 3, and 5 are clearly above the admission line; **and** +- The candidate's PR quality in this repo is judged high by the Core Team's + hands-on review. + +A waiver must be noted in the Core Team's internal record alongside the +candidate's name and the date. After the repo reaches six months old, this +waiver clause is no longer available. + +### 3. Contribution quality (Core Team judgment) + +This is qualitative and not formula-based. The Core Team looks at: + +- **Code quality** of merged PRs (correctness, scope discipline, repo-boundary respect). +- **Review quality** of any review comments left on others' PRs. +- **Community participation** — Discussions, issue triage, Discord engagement. +- **Collaboration signal** — responsiveness to feedback, willingness to revise. + +Passing the first two criteria gets you into the candidate pool. Crossing +this third threshold is what gets you nominated. + +### Selection process + +1. A Core Team member raises the candidate internally. +2. The Core Team reaches consensus. +3. A Core Team member privately reaches out to confirm the candidate is willing. +4. Onboarding. +5. Public announcement. + +There is no nomination PR, no public voting, no fixed term. The intent is +the **inverse of the K8s/Apache approver-vote model** — early in the +project's life, lightweight Core Team consensus moves faster and produces +the same quality of outcome. As the Maintainer cohort grows past five +External Maintainers, this section will be revisited. + +--- + +## Responsibilities and expectations + +**There are no hard quotas.** No weekly PR-review count, no minimum +issue-triage rate, no SLA for response time. Maintainership is recognition +of trust, not an unpaid job. + +What we ask, in spirit: + +- Approve PRs you have the context for; abstain when you don't. +- Honor the merge requirements (§ "Merge requirements") — your approval + is a real signal, not a rubber stamp. +- Keep `#maintainers` informed if you're going dark for an extended period. +- Treat the not-yet-public roadmap shared in `#maintainers` as confidential. + +If the Core Team observes a pattern of bad-case behavior (rubber-stamp +approvals, malicious issue closures, leaking unannounced roadmap, etc.), +permissions are revoked under § "Step-down — for cause". + +--- + +## Maintainer-only access + +Beyond the repository permissions listed above, Maintainers receive a few +things the wider community does not: + +- **Discord `#maintainers` channel** — a private working space shared with + the Core Team. Used for design previews, RFC drafts, and internal + coordination on the not-yet-public part of the roadmap. +- **Confidential roadmap** — early visibility into work that has not yet + been announced. Maintainers agree to treat its contents as confidential + until a Core Team member announces them publicly. +- **Direct line to the Core Team** — your `#maintainers` messages get a + faster, more substantive response than public Discussions, and the Core + Team genuinely solicits Maintainer input on architectural and roadmap + decisions. +- **Maintainer badge** — a public mark of trust on your GitHub profile and + in MAINTAINERS-related repo surfaces (rolling out once the GitHub badge + capability is in place). +- **Public recognition at promotion** — announcement across Twitter, + GitHub Discussions, and Discord when you join. + +--- + +## Step-down + +Maintainership is not a lifetime appointment. There are three exit paths. + +### Graceful step-down (voluntary) + +- The Maintainer messages the Core Team or posts in `#maintainers`. +- Permissions are revoked within 24 hours. +- The Maintainer transitions to **Emeritus** status. +- No public reason is required. + +### Inactive transition + +A Maintainer is considered for inactive transition when **any** of: + +- 90 consecutive days with no activity signal (merged PR, review comment, + issue triage, substantial Discussion or Discord participation), **or** +- 60 consecutive days without responding to any @-mention (PR review + request, issue assignment). + +Process: + +1. The Core Team @-mentions the Maintainer privately in `#maintainers`, + giving a **14-day response window**. +2. If no substantive response within 14 days, the Maintainer transitions + to Emeritus and permissions are revoked. +3. A short, kind public note is posted in GitHub Discussions: "Thanks for + your contributions — you've been moved to Emeritus, you're welcome + back any time." +4. Returning is easy — see "Emeritus" below. + +### Step-down for cause + +Triggered by: + +- Repeated bad-case behavior (e.g., rubber-stamp approvals on + substandard PRs, malicious issue closures, abuse of permissions). +- Violation of the project's [Code of Conduct][coc]. +- Security-grade incidents (compromised account not promptly reported, + intentional leak of unannounced roadmap, etc.). + +Process: + +1. Any Core Team member can open the discussion. +2. **At least 3 Core Team members** must agree before action is taken + (full Core Team consensus is not required). +3. Within 24 hours of the decision: permissions revoked, removed from + `#maintainers`, removed from any Maintainer roster (does **not** + transition to Emeritus). +4. The affected person is informed of the decision and reasons, and may + appeal once. + +The principle is **bias toward keeping the Maintainer**. A single small +lapse is not grounds for forced step-down; the for-cause path is for +repeated patterns or severe one-off incidents only. + +[coc]: https://www.contributor-covenant.org/ + +--- + +## Emeritus + +Maintainers who step down gracefully or transition through inactivity become +**Emeritus**. Emeritus status: + +- Removes write/approve/close permissions. +- Keeps the person's name acknowledged on the (internal) roster's Emeritus + section. +- Keeps Discord `#maintainers` access (read or post — Maintainer's choice). +- Carries no ongoing responsibility. + +### Returning from Emeritus + +The simplest return path: 3 merged PRs in the most recent 30 days, then +the Core Team restores permissions. No re-nomination is required. + +The point of Emeritus is to acknowledge that life happens — a sabbatical, +a job change, a kid — without any drama or social cost on either side. + +--- + +## Changes to this document + +The rules in this document are amendable by Core Team consensus. Material +changes (admission criteria, step-down thresholds) will be announced in +GitHub Discussions before taking effect for any active candidate. Editorial +clarifications can land directly. diff --git a/MAINTAINERS.pt-BR.md b/MAINTAINERS.pt-BR.md new file mode 100644 index 000000000..ba7ee2c30 --- /dev/null +++ b/MAINTAINERS.pt-BR.md @@ -0,0 +1,242 @@ + +# 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. diff --git a/MAINTAINERS.zh-CN.md b/MAINTAINERS.zh-CN.md new file mode 100644 index 000000000..1fc4f932a --- /dev/null +++ b/MAINTAINERS.zh-CN.md @@ -0,0 +1,191 @@ +# Maintainers + +English · Português (Brasil) · Deutsch · Français · 简体中文 · 日本語
+ +本文档定义了 `nexu-io/open-design` 项目中**成为、担任、退出 Maintainer** 的规则。Core Team 个人名册由内部维护，本文档不公开列出——对外公开的是大家共同遵守的规则。 + +> **状态**：v1，2026-05-11 起草。配套文档 [`CONTRIBUTING.md`](CONTRIBUTING.md#becoming-a-maintainer) 会把贡献者引到这里读完整规则。 + +--- + +## 角色定义 + +| 角色 | 权限 | +|---|---| +| **Contributor**（贡献者） | 任何提过至少 1 个 merged PR 的人，无特殊权限。 | +| **External Maintainer**（外部 Maintainer） | 按本文档规则晋升的社区贡献者。可 review、approve、关闭/重开 issue、自分配 issue。**不能点 Merge 按钮**——这一权限保留在 Core Team。 | +| **Core Team**（核心团队） | Open Design 内部团队。拥有完整仓库写权限，是治理决策的最终权威。名册由内部维护。 | + +下文除非特别说明，**讨论的都是 External Maintainer**。 + +--- + +## Maintainer 比普通 Contributor 多什么权限 + +| 操作 | Contributor | Maintainer | +|---|:---:|:---:| +| Approve PR | ⚠️ 算评论，**不**算 merge 所需的 approve | ✓ 算 merge 所需的 approve | +| 关闭 / 重开 issue | 仅自己开的 issue | ✓ 任意 issue | +| 自分配未指派的 issue（优先 P0） | ✗ | ✓ | + +### Merge 三条件 + +任何 PR——不论作者是谁——都需要**同时满足**： + +1. 无代码冲突 +2. CI 全绿 +3. 至少 1 个 Maintainer 或 Core Team 成员 approve + +Maintainer 的 approve 是绝大多数 PR 走的 merge 路径——这是 Maintainer 在项目日常中最直接的信任体现。 + +--- + +## 如何成为 Maintainer + +入选有 **3 项标准**，**全部**满足才进入候选。 + +### 1. 贡献量 + +- **≥ 20 个 merged PR** 到 `nexu-io/open-design` + +这是软门槛而非自动通行证——达到 20 PR 让你**进入考量**，不保证晋升。 + +### 2. 账号质量（防 bot / 防小号） + +我们对候选人 GitHub 资料做 7 个维度检查。**7 项中至少 5 项达准入线，且零项触发一票否决。** + +| # | 维度 | 准入线 | 一票否决线 | +|---|---|---|---| +| 1 | GitHub 账号注册时长 | ≥ 1 年 | < 90 天 | +| 2 | Public repos | ≥ 3 | 0 | +| 3 | Followers | ≥ 10 | < 3 | +| 4 | Followers / Following 比 | > 0.30 | < 0.05（典型刷号特征） | +| 5 | 资料完整度 | 自定义头像 **且** bio / company / blog / twitter 至少 1 项 | 默认头像 **且** bio/company/blog 全空 | +| 6 | 跨项目活跃 | 在 **本仓库以外** 至少 1 个公开仓库有 merged PR 或长期 issue/star 活动 | 仅在本仓库有贡献 | +| 7 | 账号状态 | 无 GitHub 平台限制（spam/banned/restored） | 任一限制 | + +#### 早期项目例外条款（仓库满 6 个月后自动失效） + +`nexu-io/open-design` 自首个 commit 起 6 个月内，**跨项目活跃**一票否决条款（#6）可由 Core Team 共识豁免，前提是： + +- 维度 1 / 2 / 3 / 5 都明显高于准入线；**且** +- Core Team 经过实际 review 判断该候选人在本仓库的 PR 质量足够高 + +豁免决定需在 Core Team 内部记录中注明候选人姓名与日期。仓库满 6 个月后，本豁免条款不再可用。 + +### 3. 贡献质量（Core Team 综合评估） + +定性评估，无固定公式。Core Team 关注： + +- **代码质量**——merged PR 的正确性、scope 控制、对仓库 boundary 的尊重 +- **Review 质量**——历史 review comment 是否有实质内容 +- **社区参与**——Discussions / issue 分流 / Discord 互动 +- **协作信号**——对 review feedback 的响应速度、修改意愿 + +通过前两项进入候选池，跨过第三项才被正式提名。 + +### 提名流程 + +1. 由某位 Core Team 成员在内部提出候选人 +2. Core Team 内部达成共识 +3. 一位 Core Team 成员私下联系候选人，确认意向 +4. 进入 Onboarding +5. 公开 announce + +**没有提名 PR、没有公开投票、没有固定任期**。这是有意做的选择——和 K8s/Apache 的 approver 投票模型相反——因为项目早期 Core Team 共识更快、决策质量相同。**当 External Maintainer 数量超过 5 人时，本节将被重新审视**。 + +--- + +## 责任与期望 + +**没有硬性指标。** 不设每周 PR review 数量、不设 issue 分流速率、不设响应 SLA。Maintainer 身份是对信任的认可，不是无薪工作。 + +我们在精神层面期望： + +- 在你有上下文的 PR 上 approve；不熟悉的 abstain +- 尊重 Merge 三条件——你的 approve 是真信号，不是 rubber stamp +- 长期离线时在 `#maintainers` 提前打招呼 +- `#maintainers` 中分享的未公开 roadmap 视为机密，不外传 + +如果 Core Team 观察到 bad-case 行为（草率 approve、恶意 close issue、泄漏未公开 roadmap 等），权限会按下节"强制退出"路径回收。 + +--- + +## Maintainer 专属权益 + +除上文所列仓库权限外，Maintainer 还会获得社区其他人没有的几样东西： + +- **Discord `#maintainers` 频道**——与 Core Team 共享的私密工作空间。用于设计预览、RFC 草稿、未公开 roadmap 的内部协调 +- **未公开 roadmap 的提前可见性**——你能在公开 announce 之前看到尚未发布的工作。Maintainer 同意在 Core Team 公开 announce 之前不外传内容 +- **直通 Core Team 的沟通**——你在 `#maintainers` 的消息会得到比公开 Discussions 更快、更实质的回应，Core Team 在架构和 roadmap 决策上会主动征求 Maintainer 的意见 +- **Maintainer 勋章**——你的 GitHub profile 与 MAINTAINERS 相关仓库表面上的公开信任标记（等 GitHub 自定义 badge 能力就绪后推出） +- **晋升时的公开认可**——Twitter / GitHub Discussions / Discord 三渠道同步 announce + +--- + +## 退出（Step-down） + +Maintainer 不是终身职位。三种退出路径： + +### 主动退出（Graceful） + +- Maintainer 私聊 Core Team 或在 `#maintainers` 公开说明 +- 24 小时内回收权限 +- 转入 **Emeritus** 状态 +- 退出原因不要求公开 + +### 不活跃自动转（Inactive） + +**触发条件**（任一即触发评估）： + +- 连续 **90 天** 无任何活跃信号（merged PR / review comment / issue 处理 / Discussion 或 Discord 实质参与），**或** +- 连续 **60 天** 未响应任何 @mention（PR review request / issue assignment） + +**流程**： + +1. Core Team 在 `#maintainers` 私下 @ 提醒，给 **14 天回应窗口** +2. 14 天内仍无实质响应 → 转入 Emeritus，回收权限 +3. 在 GitHub Discussions 公开发简短善意说明："感谢 @xxx 过去的贡献，已转入 Emeritus，欢迎随时回归" +4. 回归路径很简单——见下节 "Emeritus" + +### 强制退出（For cause） + +**触发场景**： + +- 反复 bad-case 行为（草率 approve 不达标 PR、恶意关闭 issue、滥用权限等） +- 违反项目 [Code of Conduct][coc] +- 安全级别事故（账号被盗未及时报告 / 故意泄漏未公开 roadmap 等） + +**流程**： + +1. 任一 Core Team 成员可发起讨论 +2. **至少 3 名 Core Team 成员**同意才执行（不需要全体共识） +3. 决定后 24 小时内：回收权限、移出 `#maintainers`、从任何 Maintainer 名册移除（**不**进入 Emeritus） +4. 当事人会被告知决定与理由，可申诉一次 + +原则是 **"倾向于保留 Maintainer"**——单次小过失不至于走强制路径，强制退出仅针对反复模式或严重单次事故。 + +[coc]: https://www.contributor-covenant.org/ + +--- + +## Emeritus（荣誉退役） + +主动退出或不活跃转出的 Maintainer 进入 **Emeritus** 状态： + +- 失去 write / approve / close 权限 +- 在（内部）名册的 Emeritus 区块保留致敬 +- 保留 Discord `#maintainers` 访问（read-only 或保留发言由 Maintainer 自选） +- 不再背任何责任 + +### 从 Emeritus 回归 + +最简回归路径：**最近 30 天有 ≥ 3 个 merged PR**，Core Team 即恢复权限，无需重新提名。 + +Emeritus 的意义是承认"生活会发生事"——休假、换工作、生孩子——双方都不需要任何 drama 或社交压力。 + +--- + +## 本文档的修订 + +本文档规则可由 Core Team 共识修订。**实质性变更**（准入门槛、退出阈值）会在 GitHub Discussions 提前 announce 后再对任何在审候选人生效；**编辑性澄清**可直接 land。