Skip to content
This repository was archived by the owner on Aug 15, 2026. It is now read-only.

GOVERNANCE.md

Latest commit

 

History

History
97 lines (66 loc) · 7.25 KB

GOVERNANCE.md

File metadata and controls

97 lines (66 loc) · 7.25 KB
Raw

Governance

Who decides what in the OpenSIN-AI organisation, how those decisions are recorded, and which boundaries every contributor (human or agent) must respect.

If you only need the answer to "who owns which repo?" read docs/CANONICAL-REPOS.md and stop here.

1. What this repo governs

OpenSIN-overview is the organisational map and governance index for the 205 repos under OpenSIN-AI. It MUST NOT own runtime, docs canon, config canon, or product/control-plane implementation. See BOUNDARIES.md for the full ownership map.

A change lands in this repo only if it clarifies:

  • repo roles,
  • ownership boundaries,
  • the registry of teams / agents / templates / MCPs / websites, or
  • the governance process itself.

Everything else belongs in the owning repo.

2. Roles

Role Who Scope Source of truth
Core maintainers @OpenSIN-AI/core-team May merge any PR in this repo; own every path in CODEOWNERS that is not more specifically assigned. .github/CODEOWNERS
Tier owners 1 per tier (OSS / Pro / Marketplace / Meta) Own the Go/No-Go decision for their tier. LAUNCH-CHECKLIST.md § 5 Single Ownership Rule
Team owners Varies per Team-SIN-* manifest Own the team.json content (marketing copy, agent list, pricing). templates/teams/ + provenance.owner_team in each manifest
Boundary reviewers Core maintainers Enforce BOUNDARIES.md. Reject PRs that duplicate canonical content. BOUNDARIES.md + governance/BOUNDARY-ROLE-RULES.md
Agents Any autonomous agent acting on behalf of an operator Same rights as the operator. The operator is accountable for the agent's output. CODE_OF_CONDUCT.md § Agent-specific

3. Decision process

3.1 Normal changes (the 95% case)

  1. Open a PR. Link to the issue / FOLLOWUPS ticket it resolves.
  2. Fill the PR template in full — including the Boundary Check.
  3. CI must be green (validate-links, validate-docs, validate-team-manifests).
  4. At least one CODEOWNERS match approves.
  5. Squash-merge. Commit message references the ticket (Closes #123).

3.2 Governance-level changes (the 5% case)

Things that change what this repo is (naming convention, tier model, boundary rules, canonical-repo map) require:

  • Two @OpenSIN-AI/core-team approvals, not one.
  • A one-paragraph rationale committed in the PR description AND reflected in PRODUCT-VISION.md or BOUNDARIES.md as a "DECIDED" entry with the date and PR link.
  • If the change breaks a previous public promise, add a deprecation note in docs/FOLLOWUPS.md with a migration window.

3.3 Emergency changes (launch week)

During launch week (2026-04-19 → 2026-04-30) single-maintainer fast-merges are allowed for:

  • Hotfixes to scripts/launch-status.js (dashboard must keep working).
  • Typo fixes in user-facing docs reachable from opensin.ai.
  • Freshness updates to registry/DEPLOYMENT_STATUS.md or registry/MASTER_INDEX.md generated by the regenerate script.

Everything else still needs a CODEOWNERS review, even under time pressure. No exceptions for BOUNDARIES.md, CODEOWNERS, SECURITY.md, or workflows in .github/workflows/.

4. How disagreements are resolved

  1. Discuss in the PR / issue thread. Most conflicts resolve here.
  2. Escalate to @OpenSIN-AI/core-team by pinging the team in the thread.
  3. If the core team is split: the tier owner (§2) for the tier most affected breaks the tie.
  4. If the tier is unclear: the Meta tier owner (OpenSIN-overview maintainer lead) decides.
  5. Decisions are recorded in governance/WAIVER-LOG.md if they deviate from a written rule; otherwise the PR description is the record.

No veto from outside @OpenSIN-AI/core-team can block a merge that has CODEOWNERS approval. Public feedback is welcome, but the maintainers decide.

5. Changing this document

This file itself is covered by @OpenSIN-AI/core-team in CODEOWNERS. Edits follow §3.2 (two approvals, rationale in PRODUCT-VISION.md if the org's product shape changes).

6. Related documents (in this repo)

File Role
BOUNDARIES.md What this repo MUST and MUST NOT own.
CONTRIBUTING.md Per-PR checklist for the boundary test.
CODE_OF_CONDUCT.md Behaviour standards (including agents).
SECURITY.md Vulnerability reporting.
AGENTS.md Development guidelines for agents working in this repo.
PRODUCT-VISION.md Why the tier model / UI layering / marketplace mechanic is the way it is.
LAUNCH-CHECKLIST.md Go/No-Go gates and single ownership per tier.
.github/CODEOWNERS Machine-enforced review ownership.
governance/BOUNDARY-ROLE-RULES.md Expanded rules for boundary reviewers.
governance/WAIVER-LOG.md Recorded exceptions to written rules.