[dcmcand]

Reference Issues or PRs

Implements #59, assuming it is accepted.

Note

RFD #59 was accepted on 2026-09-10, 6 of 10 Core voting yes. This is no longer
blocked on the RFD.

The relicense here needs nebari-dev/.github#50, which removes LICENSE from the file
sync so this repository owns its own. Until that merges, the next sync would overwrite
the LICENSE in this PR. The copyright lines in the two PRs are identical, so either
merge order works.

Stacked on #60, because it updates the AGENTS.md introduced there. The base is set to
that branch so the diff here shows only this change; GitHub will retarget to main when
#60 merges.

What does this implement/fix?

Put a x in the boxes that apply

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds a feature)
• Breaking change (fix or feature that would cause existing features not to work as expected)
• Documentation Update
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build related changes
• Other (please describe): relicenses this repository, and changes the scope of the Code of Conduct

Marked breaking because it removes organization-wide commit and management rights. Anyone
relying on blanket access will need a per-repository grant instead.

This is item 1 of six in the RFD's implementation outline: the governance-repo share.
Items 2 to 6 belong to nebari.dev, nebari-operator, software-pack-template,
nebari-infrastructure-core, and the organization settings, and each needs its own pull
request.

New documents

File	Covers
GOVERNANCE.md	Stewardship, scope, teams and roles, the two decision lanes, the RFD lifecycle, and the amendment clause
pack-policy.md	Official and community tiers, pack maturity, and the NebariApp contract
repository-standards.md	Licensing, branch protection, required files, docs layout, shared conventions, enforcement
trademark-and-naming.md	Use of the Nebari name and brand

Three things they deliberately do not do: restate the Pack Specification (it lives with
the operator), restate the release readiness checklist (it lives with the template), or
restate team membership requirements (they live on the website). Each is referenced instead,
so there is one copy of each fact.

Changed documents

• LICENSE relicensed from BSD-3-Clause to Apache-2.0. See the question below.
• roadmap.md is now a thin platform roadmap. The Classic yearly roadmaps are archived
  in place with a banner rather than deleted, so existing links keep working.
• CODE_OF_CONDUCT.md and code-of-conduct/coc_details.md narrow scope to
  nebari-dev organization spaces, and offer the Code of Conduct as a recommended default
  downstream instead of imposing it.
• README.md rebuilt around the new structure.
• AGENTS.md updated, and gains the rule that everything here is normative and needs an
  authorizing RFD to change.

Questions for reviewers

1. The copyright holder on the relicense. Open Resolved: OpenTeams. The old BSD
notice said Copyright (c) 2020-2022, Nebari development team. LICENSE now reads
Copyright 2020-2026 OpenTeams, keeping the authorship year range from the notice it
replaces. Flagging it for reviewers because it is a legal assertion rather than an
editorial change, not because it is still undecided.

Correcting something an earlier version of this description got wrong: the organization is
not consistent here, so this picks a form rather than matching a convention.

Repo	Copyright line
nebari-operator	Copyright 2026, OpenTeams
nebari-infrastructure-core	Copyright 2025-2026 OpenTeams
software-pack-template	Copyright [yyyy] [name of copyright owner]

This follows the infrastructure-core form. Separately, software-pack-template never had
its Apache placeholder filled in, so as written its LICENSE assigns copyright to nobody.
That is worth its own fix in that repository and is not addressed here.

2. The RFD template cannot be fixed here. The RFD asks for the template's status values
to be reconciled with the process labels. GOVERNANCE.md now defines the canonical
lifecycle, mapping each status to exactly one label. But
.github/ISSUE_TEMPLATE/RFD.md is synced in from nebari-dev/.github, so editing it here
would be reverted by the next sync. A companion pull request against that repository does
the template half.

3. Naming rules were specified as existing but did not. Section 7 is cited twice as the
home of the naming rules, and contains none. I wrote the reserve-the-name rule: community
packs must not lead with "Nebari" or use it as a product name, but "for Nebari" and
"Nebari-compatible" are always fine. Section 4's actual requirement is only that they "do
not imply official endorsement", so this is my reading of intent, not a quotation, and the
trademark holder should confirm it.

4. The RFD's example pack names do not match reality. It refers to
nebari-data-science-pack, nebari-mlflow-pack, nebari-lgtm-pack, and
nebari-software-pack-template. The actual repositories are data-science-pack,
mlflow-pack, lgtm-pack, and software-pack-template, with the nebari- prefix reserved
for platform components. The documents here use the real names, and the naming policy
records the convention as it actually is.

5. The Triage team was dropped without comment. Section 2 lists every team except
Triage, which exists on the website today with real members. Rather than silently deleting
it, GOVERNANCE.md follows what the RFD does say about triage being granted per-repo, and
records that existing members keep triage on repositories they are active in. Core should
confirm that reading.

6. The security baseline does not exist yet. Three documents reference it as a
Core-owned artifact, per the RFD, but there is no such document. Those references are
forward-looking. It is presumably part of the Pack Specification work in nebari-operator.

Testing

• Did you test the pull request locally?
• Did you add new tests?

Documentation-only repository with no test suite, so there is nothing to add tests to. What
was verified instead:

• Every cross-document anchor resolves. These documents reference each other by anchor
  heavily, and a bad anchor fails silently on GitHub. All 47 anchor links were checked
  against the actual headings, including a corrected slug algorithm (GitHub does not
  collapse repeated hyphens, which an earlier check got wrong).
• Every relative path resolves, using the checker documented in AGENTS.md.
• The Apache-2.0 text is byte-identical to nebari-operator's, differing only on the
  copyright line, so the organization's license files genuinely match rather than being
  separately typed.
• Each requirement was traced back to the RFD: all seven platform-RFD triggers, all five
  Section 5 maturity revisions, and the required-versus-recommended split of the branch
  protection settings.

Three pre-existing broken links were found during that verification and fixed, all in files
this pull request already touches: the committee link in CODE_OF_CONDUCT.md pointed at
./coc_enforcement.md instead of code-of-conduct/coc_enforcement.md, and the archived
2023 roadmap had a table-of-contents anchor pointing at the 2022 heading plus a reversed
markdown link.

Documentation

The pull request is documentation. Two follow-ups it creates:

• This repository does not yet meet its own standard. repository-standards.md requires
  MAINTAINERS.md and SECURITY.md in every public repository, and this one has neither.
  I did not add them, because both need real names and a real vulnerability-reporting route,
  and inventing either would be worse than leaving the gap visible.
• The website pages for team structure and decision-making now describe the old model and
  need rewriting (item 2 of the outline).

Access-centered content checklist

Text styling

• The content is written with plain language (where relevant).
• If there are headers, they use the proper header tags (with only one level-one header: H1 or # in markdown).
• All links describe where they link to (for example, check the Nebari website).
• This content adheres to the Nebari style guides.

Non-text content

• All content is represented as text (for example, images need alt text, and videos need captions or descriptive transcripts).
• If there are emojis, there are not more than three in a row.
• Don't use flashing GIFs or videos.
• If the content were to be read as plain text, it still makes sense, and no information is missing.

Verified mechanically: one H1 per file, no em dashes, no runs of more than three emojis.
The only images are the existing logo block in README.md, whose alt text is unchanged.

Any other comments?

The documents try hard to distinguish three things the RFD is careful about and that are
easy to blur: what is required, what is recommended and deliberately not required
(signed commits, linear history, up-to-date branches, each with the reason), and what
does not exist yet (the community-pack catalog, the promotion process, the security
baseline). Where the RFD admits a gap, these documents admit it too rather than writing
around it.