GOVERNANCE.md
This document defines the governance of the Meshery project. It describes the project's values, its structure across the two GitHub organizations that make up the Meshery ecosystem, the roles that people hold, how those roles are earned and relinquished, how decisions are made, and the systems and permissions that back each role. It is an open, living document that the project iterates on as the community and the project change.
Meshery is a Cloud Native Computing Foundation (CNCF) project. Where this document does not address a matter, the project defers to the CNCF Charter and the CNCF Technical Oversight Committee (TOC).
The Meshery project and its leadership embrace the following values. These values apply to everything the project does, and every person in a leadership role is expected to uphold them.
Meshery is a vendor-neutral project.
To serve a large and growing ecosystem, the Meshery project is partitioned into two GitHub organizations:
This separation lets the core maintainers keep the core platform robust and focused while
enabling broad community participation around it. It mirrors the approach taken by
graduated CNCF projects, including Kubernetes (kubernetes and kubernetes-sigs),
Crossplane (crossplane and crossplane-contrib), and Argo (argoproj and
argoproj-labs).
Throughout this document, "the project" refers to the entire Meshery ecosystem across both organizations.
github.com/meshery)The core platform is governed by the Meshery core maintainers under this document. It provides full support: regular updates, bug fixes, security response, and comprehensive documentation. Changes follow a structured release cycle with stable and edge channels and undergo rigorous review to sustain stability.
The core platform is organized into subprojects (also called domains), each focused on a component or an area of concern. See Subprojects below.
github.com/meshery-extensions)Extensions allow the ecosystem to scale beyond what the core maintainers can directly support, and they act as an incubator for new ideas that may or may not later migrate toward the core. Extensions can be initiated, developed, and maintained by members of the community rather than by the core maintainers.
Extensions operate under a lighter governance structure to encourage innovation:
The following table summarizes the difference in governance between the two organizations.
| Aspect | Core Platform | Extensions |
|---|---|---|
| Governance | Structured, led by the core maintainers (the Maintainer Council) under this document | Flexible, led by per-extension maintainers under lighter rules |
| Maintainer selection | Nomination and a 2/3 majority vote of existing core maintainers | Nomination or self-nomination, confirmed by the core maintainers |
| Decision-making | Lazy consensus, with voting where required | Extension-team consensus, with core oversight |
| Support | Full support and documentation | Variable; labeled Official or Community |
| Communication | Public meetings, Slack, forums | Public issues, Slack, optional meetings |
Within the core platform, work is organized into subprojects. A subproject is a technically distinct area that has its own maintainers and its own day-to-day operations, while remaining aligned with the overall project. Depending on context, the project also refers to these as domains or, following the Kubernetes model that inspired this structure, as the project's equivalent of Special Interest Groups.
Representative subprojects include, but are not limited to:
Each subproject is governed by its maintainers as a maintainer team. The authoritative, current list of subprojects, the repositories and directories each owns, and the maintainers responsible for each is recorded in MAINTAINERS.md (see Appendix B). Each subproject designates one of its maintainers as a Subproject Lead.
To ensure global coordination and a coherent vision for the project as a whole, each subproject and its lead participate in the Maintainer Council.
The project defines a ladder of roles. Anyone can enter at the bottom, and each rung has a clear set of requirements, responsibilities, and privileges. Movement up the ladder is based on demonstrated, sustained contribution. Both code and non-code contributions count toward advancement, and non-code leadership roles such as Community Manager and MeshMate are recognized first-class roles.
The rungs, in ascending order of responsibility, are: Community Participant,
Contributor, Organization Member, Maintainer, and Subproject Lead. Maintainers fall
into two classes that reflect the project's two organizations: core maintainers,
who maintain the core platform in github.com/meshery and collectively form the
project's governing body, and extensions maintainers, who maintain extensions in github.com/meshery-extensions under a
lighter governance. Community Manager and MeshMate are non-code leadership
distinctions that overlay this ladder.
Anyone who uses Meshery, asks questions, files issues, joins the Slack or the discussion forum, or attends a community meeting is a community participant. No special permissions are required, and participation requires only agreement to the Code of Conduct. Community participants have read access to the project's public repositories.
A Contributor is anyone who contributes to the project, with code, documentation, design, community work, or other means.
How to become a Contributor. Open a pull request, file or triage an issue, improve documentation, help others in Slack or the forum, or otherwise contribute, and follow the steps in CONTRIBUTING.md. There is no application and no waiting period: making an accepted contribution makes you a Contributor. First-time contributors are encouraged to start with issues labeled help wanted and to find a MeshMate for guidance.
What a Contributor can do.
A current list of contributors is published at the project's contributor list and celebrated through meshery.io/community/members.
Reviewing work in progress. Everyone is welcome to review and comment on open pull requests and issues. The project does not maintain a separate, gated "Reviewer" role: review and feedback are open to all. The authority to approve a change for merge is held by the maintainers responsible for the affected code or documentation, as recorded in MAINTAINERS.md (see Systems Access and Repository Permissions).
Organization Members have triage access across the repositories in the
organization. Triage access allows a person to manage issues and pull requests
(labeling, assigning, requesting reviewers, and closing or reopening) without write
access to code.
How to become an Organization Member. A Contributor may request organization membership once they meet the following requirements, which are evaluated by the maintainers of the area in which the person is active and, where needed, by the core maintainers:
To request membership, open an issue in the relevant repository stating that you meet the requirements and naming your sponsoring Maintainer. A Maintainer adds approved members to the appropriate GitHub team.
What an Organization Member can do. In addition to everything a Contributor can do, Organization Members can triage issues and pull requests across the organization, which materially helps the project keep its backlog healthy.
Maintainers are individuals who have demonstrated dedication to the betterment of the project and the sustained good judgment to steward an area of it. A Maintainer is both a Project Maintainer for CNCF purposes and an approver for the part of the project they maintain.
A Maintainer is not merely someone who can make changes. A Maintainer is someone who has shown the ability to collaborate with the community, support contributors, bring the most knowledgeable people in to review code and documentation, contribute high-quality work, and follow through to fix issues in code or tests. Maintainers uphold the project's standards of process, code convention, architectural principles, and respectful treatment of contributors. No task is beneath a Maintainer when it serves the project and its community.
Maintainership is held per subproject, and Maintainers fall into two classes that correspond to the project's two organizations.
Core maintainers maintain the core platform in github.com/meshery. They are the project's CNCF Project Maintainers, and collectively they form the Maintainer Council, the project's governing body. A core maintainer maintains one or more core subprojects (Server, UI, CLI, Schemas, MeshSync and Operator, Documentation, Community and Governance, and so on). The core maintainers of a given subproject are responsible for adding and removing the core maintainers of that subproject, which does not require approval from the Maintainer Council, and for designating that subproject's Lead. Beyond their own subproject, core maintainers carry project-level governance responsibility, including the oversight of extensions and the decisions described throughout this document.
Extensions maintainers, maintain individual extensions in github.com/meshery-extensions. They have autonomy over their extension's development and release cadence under the lighter governance described in Extensions, provided they adhere to the Code of Conduct, the core component frameworks, and the integration guidelines. Extensions maintainers are confirmed by the core maintainers, they are not members of the Maintainer Council, and their authority is scoped to the extensions they maintain. Sustained, high-impact work as an extensions maintainer is one of the paths toward becoming a core maintainer.
The complete, current list of maintainers, the class of each, the repositories and
directories each is responsible for, and each maintainer's contact information and
affiliation, is maintained in MAINTAINERS.md. See the
Maintainer Lifecycle for how these roles are earned,
exercised, and relinquished, and
Appendix B for the structure of
MAINTAINERS.md.
Each subproject designates one of its Maintainers as its Lead. The Lead is a Maintainer who additionally:
A subproject's Maintainers select and may replace their Lead by simple majority. The current Lead of each subproject is recorded in MAINTAINERS.md.
Community Managers are responsible for the health and growth of the community. A Community Manager serves as a link between the project and its community, working across teams to resolve obstacles before and as they arise. Their work includes:
Community Manager is a non-code leadership role. Sustained, high-impact community work is a recognized path up the contributor ladder, including toward Maintainership of the Community and Governance subproject.
MeshMates are experienced community members who help others become successful contributors. MeshMates help newcomers identify areas of the project to engage with, working groups to join, and ways to grow their open source and cloud native knowledge, often by connecting one-on-one and sharing tips for the best community experience.
MeshMate is a distinction awarded to select members of the community who embody the project's culture of helping others, paying it forward, and sharing knowledge. MeshMates are community ambassadors, not employees. As with other roles, the project recognizes Emeritus MeshMates who have previously served with distinction. Learn more and find a MeshMate at meshery.io/community/meshmates.
The project recognizes contributions, both code and non-code, through a public recognition program that awards badges for milestones, skills, and roles. Recognition is one of the ways the project makes the contributor ladder visible and celebrates progress along it. Badges fall into several categories: achievement badges for user milestones such as a first deployment, project badges for contribution milestones, community badges for community and no-code contributions such as the MeshMate badge, and certification badges earned by passing a Meshery certification such as the Certified Meshery Contributor.
The CMC is the first certification in the broader Meshery Certification Program, a structured pathway for validating skills across the ecosystem. The program is organized into a Developers track (Certified Meshery Contributor and Certified Meshery Developer) and an Administrators track (Certified Meshery Associate, Certified Meshery Professional, and Certified Meshery Expert). It complements the project's recognition program by adding a certification badge category.
The Certified Meshery Contributor (CMC) is the project's contributor certification and the first contributor certification of its kind in the CNCF. It validates a contributor's technical proficiency across Meshery's major architectural domains through written assessments, giving contributors a way to demonstrate and validate their expertise as part of the project's onboarding and recognition experience.
The CMC comprises five exams, one for each of Meshery's major architectural domains: Meshery Server, Meshery CLI, Meshery UI, Meshery Models, and Meshery Extensibility. The exams are created and reviewed by the maintainers of each domain, which keeps the certification aligned with how the project actually works. It is aimed at developers with intermediate proficiency in Go, React, and OpenAPI schemas and hands-on experience in the codebase, and it is open to developers, technical writers, and community members. The exam is a free, online, multiple-choice assessment, two hours in duration, with a 70% passing score and a two-year validity. No minimum number of contributions is required to sit for it. See the recognition program.
The Maintainer Council is the top-level governing body of the Meshery project. It is the collective body of the project's core maintainers, with each core subproject represented through its core maintainers and its Lead. The members of the Maintainer Council are the project's owners as far as the CNCF is concerned. Extensions maintainers are not members of the Maintainer Council; they govern their extensions under lighter rules and coordinate with the core maintainers.
Meshery deliberately governs itself through a Maintainer Council rather than through a separately elected steering committee. This reflects how the project actually operates: the people who approve changes to critical parts of the project are the same people who handle its overall direction. The Maintainer Council therefore performs the steering and oversight functions for the project, and this section supersedes earlier references in project documents to a separate "steering committee."
The Maintainer Council is responsible for:
github.com/meshery) and extensions (github.com/meshery-extensions), including
approving new subprojects and extensions and resolving conflicts that cannot be
handled within a single subproject.The Maintainer Council may delegate any of its powers to an individual, a subproject, or a smaller team. Day-to-day technical decisions are handled within each subproject; the Council exists for what cannot be, or should not be, decided within a single subproject.
Most business in Meshery is conducted by lazy consensus. Proposals move forward when there is no sustained objection. The project does not take a formal tally for routine decisions, which are made in issues, pull requests, discussions, and meetings.
A formal vote is taken when any of the following is true:
Votes are held in a GitHub issue labeled vote in the relevant repository, or on a
Maintainer communication channel, and remain open long enough for Maintainers in
different time zones to participate (normally one to two weeks for nominations).
Votes are counted against the total number of eligible Maintainers, not against the number who happen to participate. This lets the project be flexible about where and how a vote is held, because there is little risk of deliberate exclusion. The applicable thresholds are:
For a vote scoped to a single subproject, "eligible Maintainers" means the Maintainers of that subproject. For a project-wide vote, it means the Maintainer Council.
MAINTAINERS.md. Anyone may
review and comment; approval authority rests with those maintainers.This section defines how a person becomes a core maintainer, is onboarded, what they are responsible for and entitled to, and how the role ends, whether voluntarily, through inactivity, or into emeritus status. A working maintainer lifecycle, including removal, is essential to prevent the project from stalling when people move on.
Unless stated otherwise, this lifecycle describes core maintainers. Extensions maintainers follow the lighter path described under Extensions: they are nominated or self-nominated and confirmed by the core maintainers, and the onboarding, inactivity, and emeritus practices below apply to them within the extensions they maintain.
New core maintainers are selected through a transparent, merit-based process:
When a person becomes a core maintainer:
write, and maintain
where required). See
Systems Access and Repository Permissions.Maintainership is largely more of what a consistently engaged and impactful contributor already does. Responsibilities include:
These responsibilities come with the following:
Maintainers may step down voluntarily at any time. If you decide to step down, please inform the other Maintainers and explain your reasons. Before stepping down, please help identify and train your replacement and ensure a smooth handover. When ready, you or another Maintainer submits a pull request moving your name from the active list to the Emeritus Maintainers list in MAINTAINERS.md, and another Maintainer adjusts your permissions and access accordingly, including removal from the CNCF Project Maintainers list.
Continuity depends on active Maintainers, so the project removes Maintainers who have become inactive.
Removal is not a judgment of a person's past contributions. A removed Maintainer is welcome to re-earn the role later through the normal process.
Emeritus Maintainers are former Maintainers who have stepped down or become inactive but whose past contributions the project continues to recognize. Emeritus Maintainers are listed in MAINTAINERS.md. They hold no special permissions and are not counted when computing vote thresholds, but they are welcome to participate as Contributors and may return to active Maintainership through the normal nomination and voting process.
A new subproject or extension may be proposed by any Maintainer or by a group of contributors who intend to maintain it. A proposal:
github.com/meshery for core areas, github.com/meshery-extensions for
community extensions).Core subprojects are admitted by a 2/3 vote of the core maintainers. Extensions
in github.com/meshery-extensions are admitted by confirmation from the core
maintainers, based on the maintainers' contribution history and the extension's quality
and compatibility, consistent with the lighter governance described in
Extensions.
The project may admit an experimental subproject or extension that shows promise but does not yet have production-ready code or an established pool of maintainers. Experimental subprojects are clearly labeled as such, are given a route to join the ecosystem without the same expectations and authority as established subprojects, and are expected either to graduate to full status or to be archived within a reasonable period.
A subproject or extension may be archived when it is no longer maintained, no longer aligns with the project, or has been superseded. Core subprojects are archived by a 2/3 vote of the core maintainers; extensions are archived by the core maintainers in coordination with their maintainers. Archived repositories are moved to the project's archive (attic) and marked read-only, with a note pointing to any replacement.
This section documents the mechanics of the project's roles: which systems and permissions back each role, and how access is granted and revoked. Code and documentation ownership in GitHub and elsewhere is kept consistent with the roles defined in this document.
The project uses GitHub's permission levels and grants them through GitHub teams, so that access follows role rather than individual. The mapping is:
| Role | GitHub permission | How it is granted |
|---|---|---|
| Community Participant | Read (public) | Default for public repositories |
| Contributor | Read; contributes via forks and pull requests | No grant required |
| Organization Member | Triage across org repositories | Added to the org members team after meeting requirements |
| Core maintainer | Write (and Maintain where required) on the core repositories and directories they own in github.com/meshery | Added to the subproject's GitHub team |
| Extensions maintainer | Write (and Maintain where required) on the extension repositories they maintain in github.com/meshery-extensions | Added to the extension's GitHub team |
| Subproject Lead | Maintain on the subproject's repositories | Added to the subproject's lead team |
| Organization administration | Admin | Held by a small number of core maintainers, designated by the Maintainer Council |
Admin access is limited to the smallest practical number of maintainers needed to
administer each organization. Granting or revoking Admin is a decision of the core
maintainers.
@meshery/maintainers and per-subproject teams (for example, a server team, a UI
team, a docs team). Adding a person to the appropriate team is how their role's
access is granted; removing them is how it is revoked.meshery/meshery, meshery/schemas, meshery/meshsync, and
directories within them), their subproject and Lead status, and their affiliation.
It also lists Emeritus Maintainers. This list is kept in sync with the
CNCF Project Maintainers list.Branch protection on the default branch requires review and approval from the maintainers responsible for the affected area before merge, which is how the project ensures that ownership in GitHub matches the governance roles in this document.
Access to the project's other systems also follows role and is granted at onboarding and revoked at offboarding:
When a person changes or leaves a role, the Maintainers and Community Managers responsible for each system update access accordingly.
The project conducts its work on public, vendor-neutral channels. All channels, including those used by subprojects, are listed here. Any non-public channel and its purpose is also listed.
Public channels:
Non-public channels:
The project holds regular, public meetings, and their schedule is published on the community calendar and integrated with the CNCF calendar. These include weekly community and newcomer meetings, where official project decisions may be made, alongside discussion in issues, pull requests, and on the forum. Anyone is welcome to join; see meshery.io/community and the community handbook. Meetings are recorded and posted publicly.
The project adopts and adheres to the Meshery Code of Conduct, which is based on, and not in conflict with, the CNCF Code of Conduct. All community members, in both organizations and across all channels, are expected to follow it.
Code of Conduct reports are received confidentially by the core maintainers. If a report concerns a core maintainer, the core maintainers designate two uninvolved core maintainers to handle it. Reports that require a full investigation, or that involve a core maintainer, are forwarded to the CNCF Code of Conduct Committee for handling, and the core maintainers appoint a non-involved contributor to work with the Committee as needed.
The core maintainers appoint a Security Response Team to handle reports of security vulnerabilities. This team may consist of the core maintainers themselves; if the responsibility is delegated, the core maintainers appoint a team of at least two contributors. The core maintainers review the composition of the Security Response Team at least once a year.
The Security Response Team handles all reports according to the project's Security Policy. Vulnerabilities are reported privately to [email protected] and are acknowledged within the timeframe stated in the security policy. Maintainers receive advance notice of unannounced vulnerabilities and help coordinate the fix and public disclosure.
Any Maintainer may suggest a request for CNCF resources by filing an issue in the project's community repository. A simple majority of the core maintainers approves the request. The core maintainers may also delegate working with the CNCF to non-maintainer community members, such as Community Managers, who are then added to the CNCF Project Maintainers list for that purpose.
Everyone is welcome to contribute. Start with the Contributor Guides and CONTRIBUTING.md, the Newcomers' Guide, and the community handbook. Good first issues are labeled help wanted, and a MeshMate can help you get started.
Contribution expectations include:
git commit -s).[component] message convention and
reference related issues and pull requests.The project's direction and upcoming work are described in the Roadmap.
This document is expected to evolve as the project does. Changes are proposed through a pull request to this file and are adopted by a 2/3 vote of the Maintainer Council. Material changes are announced to the community. The project keeps the history of this document in version control so that the evolution of its governance remains visible alongside the evolution of the project itself.
This governance builds on the project's prior governance and continues to iterate on
it as the project has grown, including the
2026 reorganization
that partitioned the ecosystem into the meshery and meshery-extensions
organizations. It draws on the CNCF Contributor Strategy
Maintainer Council
and Subprojects
governance templates, and on the practices of graduated CNCF projects, including the
Kubernetes governance
and OWNERS model.
This appendix maps each consideration in the CNCF TOC
Governance Review Template
to where it is addressed, so the project and reviewers can confirm coverage during
Incubation diligence. It is a self-assessment companion to this document and may be
maintained as part of the project's Incubation self-assessment rather than published
as part of GOVERNANCE.md. Levels shown are the template's: R = Required at
Incubation, S = Suggested at Incubation (and typically Required at Graduation).
| # | Criterion | Level | Where addressed |
|---|---|---|---|
| 1 | Governance evolution / history | S | Governance Lineage; version history of this file |
| 2 | Clear and discoverable governance documentation | S | This GOVERNANCE.md, linked from the README and contributing guides |
| 3 | Governance up to date with actual activities (meetings, elections, leadership, approvals) | S | Meetings, Decision-Making, Maintainer Lifecycle |
| 4 | Vendor-neutrality of project direction documented | S | Vendor Neutrality |
| 5 | How the project decides leadership roles, contribution acceptance, requests to CNCF, and governance/goal changes | S | Decision-Making, Requesting CNCF Resources, Changes to This Governance |
| 6 | How role/function-based members or sub-teams are assigned, onboarded, and removed (e.g., Security Response) | S | Security Response, Subproject Lifecycle, Systems Access |
| 7 | Complete maintainer lifecycle (roles, onboarding, offboarding, emeritus) | S | Maintainer Lifecycle |
| 8 | Demonstrated use of the maintainer lifecycle (additions/replacements) | S | Record outcomes in MAINTAINERS.md history (active and emeritus changes) |
| 9 | Complete list of current maintainers with names, contact, domain of responsibility, and affiliation | R | MAINTAINERS.md; structure in Appendix B |
| 10 | A number of active maintainers appropriate to size and scope | R | MAINTAINERS.md (maintain active count across subprojects) |
| 11 | Maintainers from at least 2 organizations (survivability) | N/A at Incubation | Affiliation column in MAINTAINERS.md |
| 12 | Code and doc ownership in GitHub matches documented governance roles | R | Systems Access and Repository Permissions |
| 13 | Adoption and adherence to CNCF CoC, or a project CoC based on it | R | Code of Conduct, CODE_OF_CONDUCT.md |
| 14 | CNCF CoC cross-linked from other governance documents | R | Code of Conduct links the CNCF CoC |
| 15 | All subprojects listed | R | Subprojects and domains; MAINTAINERS.md for the authoritative list |
| 16 | Subproject leadership, contribution, maturity status, and add/remove process documented | S | Subprojects, Subproject Lifecycle |
| 17 | Contributor ladder with multiple roles | S | Roles and the Contributor Ladder |
| 18 | Clearly defined and discoverable process to submit issues or changes | R | How to Contribute, CONTRIBUTING.md |
| 19 | At least one public communications channel documented | R | Communication Channels |
| 20 | All communication channels listed, including subprojects and any non-public channels and their purpose | R | Communication Channels |
| 21 | Up-to-date public meeting schedule / CNCF calendar integration | R | Meetings; community calendar |
| 22 | Documentation of how to contribute, with increasing detail as the project matures | R | How to Contribute; contributing guides |
| 23 | Demonstrated contributor activity and recruitment | R | contributor list, MeshMates, recognition program, newcomer meetings |
Resolution of the open governance issues. This document also resolves the two open governance issues that prompted this work:
MAINTAINERS.md; the
document states how maintainer rights are granted (GitHub teams) and revoked,
including the two-month inactivity rule.This appendix specifies the structure that satisfies criterion 9 and issue #19447. It
is a template, not a list of people; the live data lives in MAINTAINERS.md.
MAINTAINERS.md lists, for every Maintainer, at least the following, grouped by
subproject:
| Column | Description |
|---|---|
| Name | The maintainer's name |
| GitHub handle | Used to map to GitHub teams |
| Class | Whether the person is a core maintainer or an extensions maintainer |
| Contact | A reachable contact, such as email or Slack handle |
| Subproject | The subproject, domain, or extension, and whether the person is its Lead |
| Repositories and directories | The specific repositories and paths the person is responsible for, for example meshery/meshery (/server, /mesheryctl), meshery/schemas, meshery/meshsync, or an extension under meshery-extensions |
| Affiliation | The person's employer or "independent", for vendor-neutrality tracking |
MAINTAINERS.md also contains an Emeritus Maintainers section and a note that the
list is kept in sync with the
CNCF Project Maintainers list.
If a repository in either organization lacks its own MAINTAINERS.md, the
authoritative mapping for it is the entry in
meshery/meshery/MAINTAINERS.md.