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 care1.
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 members2, 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 |
- Members can attend any form of online or in-person training on dealing with CoC reports.↩
- All except the Emeritus core team are decided through nominations.↩