open-design/MAINTAINERS.md

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 — 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.
• 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.

---

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.