Project roles and teams

The Nebari project has a team-based governance structure, implemented transparently using GitHub's team features. This page documents the different teams, their privileges and responsibilities, and how you can join the teams.

tip

Use the table of contents in the right sidebar to jump to different sections of this page.

Teams

The following teams are formally recognized by Nebari.

Triage

Members responsible for triaging and improving new and existing issues & pull requests (PRs) across all repositories. They can add relevant labels to issues/PRs, edit issue/PR titles and descriptions to improve them, and transfer issues between repositories.

Contributors

People who make valuable contributions to the Nebari projects in the form of code contributions, documentation improvements, or design enhancements, issues/PR triage, community management, fundraising, advocacy, and more. Members of this team have commit rights across all Nebari repositories, which includes access to triage permissions.

Core

Project sustainers who lead and maintain the overall Nebari project and community. They are the core and final decision-makers on project-wide initiatives, and have repository-level management rights across all Nebari projects.

Owners

A private and small subset of the Core team who have organization-level privileges for nebari-dev. While decisions are made by the entire Core team, the Owners group has relevant permissions to implement certain decision like adding new team members.

Code of Conduct response team

Community members responsible for upholding and enforcing Nebari's Code of Conduct. This team is documented in the Nebari governance repository. At least one member of this team should also be in the Nebari Core team, and all members should be trained to handle CoC reports with care¹.

Emeritus core

The Emeritus core team recognizes community members who choose to step away from the Core team. Open source projects have members join, retire, and return as the project matures. Contributors can move on for various reasons including limited bandwidth, conflicting or changing interests, burnout, boredom, personal reasons, and much more.

Nebari Core team members can step away at any time, and we hope for them to communicate this to the rest of the Core team early when possible. They can share as much or as little details as they are comfortable sharing for this move. We also hope they can work with the team for a smooth transition, but we do understand if sometimes this may not be possible. Fellow core team members are expected to support off-boarding members for a graceful transfer of responsibilities.

Emeritus members are welcome return to the project as active participants, and join the core team again through the process of nomination described earlier.

Special interest or working groups

In addition to the formal teams, new special interest groups (SIG) can be created with commit and triage access to specific Nebari repositories. In the past, examples of special interest groups are "Documentation" and "Design" teams. The core team is responsible for the approval and dissolution of SIGs.

The Core team can create a new SIG if two or more community members express interest in the discussion forum.

Join a team

Nebari follows a nomination process to add new team members², as detailed in the following table. You can nominate members by opening a GitHub discussions topic in the "Community" category.

Team	Requirements for nomination	Nominators	Approvers
Triage	Engage with (create or comment on) one or more issue/PR/discussion in nebari-dev	Any community member (including self)	Any Core team member
Contributor	Two or more contributions to Nebari with intention to continue contributing regularly	Any community member (including self)	Any Core team member
Core	Contributors team member with a record of regular, valuable, and high-quality contributions to Nebari for at least one month	Any community member (including self) and one Core team member	Core team makes a consent-based decision
Conduct	Member of the Contributor or Core Team with adequate training to handle CoC reports	Any community member (including self)	Core team makes a consent-based decision

Footnotes

1. Members can attend any form of online or in-person training on dealing with CoC reports. ↩

2. All except the Emeritus core team are decided through nominations. ↩