Repository navigation
Conversation
These two pages described governance built for Nebari Classic, a single monolithic platform shipped from one repository. They granted Contributors "commit rights across all Nebari repositories" and Core "repository-level management rights across all Nebari projects", and assumed every decision of consequence reached one central team. Team structure: - Access is per repository, following least privilege. The claim of org-wide commit is gone, because it was both a security problem and meaningless across dozens of independently versioned repositories. - Core's mandate is narrowed to the seams it actually owns: the Pack Specification, the auth, routing and TLS conventions, the security baseline, the standards, the official designation, the trademark, and platform RFDs. It no longer claims authority over every repository. - Pack maintainers are documented as a role, holding access on their own repository and listing themselves in that repository's MAINTAINERS.md. - Triage becomes a per-repository grant rather than a standing team. Existing Triage members keep access where they are active. - SIGs are retired, since a pack repository is now what a SIG used to approximate. Ad-hoc working groups remain available for cross-cutting topics. Decision making: - Two lanes, with the repository-local one first because it covers the overwhelming majority of decisions. Platform RFDs are the exception, and the triggers are listed rather than left to judgement. - How votes are counted is now written down: which reactions count, that each person counts once, that bots are excluded from the denominator, and that "more than 50%" means strictly more than half. - A vote taken in a meeting has to be recorded on the issue with the date and who was present, or it is treated as not yet decided. An earlier RFD reached consent in a meeting and left no trace, which made it impossible to record honestly weeks later. Also fixes the RFD issue link, which pre-filled the label "type: RFD" without its emoji. No such label exists, and GitHub silently drops labels it cannot match, so RFDs opened from that link arrived unlabelled. The full model lives in nebari-dev/governance. These pages describe the teams and the process and link there rather than restating policy. Item 2 of the implementation outline in nebari-dev/governance#59.
✅ Deploy Preview for nebari-docs2 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements item 2 of the implementation outline in
RFD #59, accepted 2026-09-10.
Refs nebari-dev/governance#59
Why
These two pages describe governance built for Nebari Classic: one monolithic platform
in one repository. They grant Contributors "commit rights across all Nebari repositories"
and Core "repository-level management rights across all Nebari projects", and assume every
decision of consequence reaches one central team.
The platform is now a stable infrastructure core plus many independently developed packs,
each in its own repository. Org-wide blanket commit is both a security problem and
meaningless at that shape, and routing every decision through Core reintroduces exactly the
bottleneck the new architecture removed.
team-structure.mdconventions, the security baseline, the standards, the official designation, the
trademark, and platform RFDs. It no longer claims authority over every repository.
listed in that repository's
MAINTAINERS.md, which is authoritative rather than this page.existing Triage members keep access where they are active. Flagging this because the RFD's
role list omits Triage entirely while the team exists today with real members; this
follows what the RFD does say about triage being granted per-repo.
working groups remain available.
core-teamGitHub team is the authoritative record of Core membership,because its human size is the denominator for an RFD vote.
Deliberately preserved: the nomination process, the identity-verification heuristics, the
leave-a-team process, and the inactivity rule. The RFD does not change any of it, and it is
good material.
decision-making.mddecisions. Platform RFD triggers are listed rather than left to judgement.
counts once however many they leave, that bots are excluded from the denominator, and that
"more than 50%" means strictly more than half, so ten members takes six votes rather than
five.
present, or it is treated as not yet decided.
Those last two are not cosmetic. RFD #59 itself reached consent in a meeting that left no
trace on the issue, which made it impossible to record honestly weeks later; and tallying
its vote produced two different answers depending on whether ❤️ counted and who was on
Core. Both gaps are now closed here and in
GOVERNANCE.md.Bug fixed along the way
The RFD issue link pre-filled the wrong label:
labels=type%3A+RFD, without the emoji.No label of that name exists, and GitHub silently drops labels it cannot match, so RFDs
opened from that link arrived unlabelled. Now
type%3A+RFD+%F0%9F%97%B3.The same bug existed in the issue template itself and is fixed in
nebari-dev/.github#49.
Testing
yarn run buildsucceeds. This config setsonBrokenLinks: "throw", so the build isa real check on every link I touched, and it passes.
/classic/how-tos/configuring-keycloak,three
/classic/*pages that link to it, and/community/maintainers/release-process-branching-strategy. None are in these two pages,and I have left them alone.
./maintainers/triage-guidelines,./file-issues#working-on-issues-to-improve-them(theid of
issues.md), and/community/introduction/#how-to-contribute.prettier@3.3.3run with this repo's.prettierrc, so the diff is whatlint-stagedwould produce at commit time rather than leaving a formatting-only follow-up.
sidebarsCommunity.jsneeds no edit.Note for reviewers
These pages now describe teams and process and link to the governance repository for policy,
rather than restating it. That split is deliberate, per the RFD: policy has one home, so the
two cannot drift apart the way the RFD status vocabulary did.