GOVERNANCE.md
This document defines governance policies for the Meshery project.
Anyone can become a Meshery contributor simply by contributing to the project, with code, documentation or other means. As with all Meshery community members, contributors are expected to follow the Code of Conduct.
GitHub organization members are people who have triage access to all repos in the organization. Community members who wish to become members of the organization should meet the following requirements, which are open to the discretion of the steering committee:
The Meshery project consists of multiple repositories. Each repository is subject to the same governance model, but different maintainers and reviewers. See [Maintainer Teams](#maintainer teams).
The current maintainers of a repo can be found in MAINTAINERS.md file of the repo.
Maintainers are individuals that have demonstrated their dedication the betterment of the project and dedication to Maintainers are empowered to review, approve, merge, close issues and pull requests. Maintainers are empowered to make releases. These individuals are most experience with the given project (or specific repo) and are expected to lead its growth and improvement. Adding and removing maintainers for a given repo is the responsibility of the existing maintainer team for that repo and therefore does not require approval from the steering committee.
This privilege is granted with some expectation of responsibility: maintainers are people who care about the Meshery project and want to help it grow and improve. A maintainer is not just someone who can make changes, but someone who has demonstrated his or her ability to collaborate with the community, support contributors, perform menial tasks - no task is beneath them as it pertains to the betterment of the project and its community. Maintainers uphold standards of process, code convention, architectural guiding principles, and treatment of contributors. Maintainers are the most knowledgeable individuals to review code, contribute high quality code, and follow through to fix issues (in code or tests).
A core team of maintainers steward Meshery, however, Meshery is comprised of any number of components (adapters, operators, ...) and any number of logical areas of concern (e.g. community, governance, ...). The size of Meshery's project vision and the pace of its development, requires sub-teams to supplement the core team. Each sub-team is focused on a specific area/component e.g., adapters, docs, website, UI, CLI, and so on. To ensure global coordination and a strong, coherent vision for the project as a whole, each sub-team is led by a member of the core team.
The process of nominating and voting for maintainers involves the following steps:
This process ensures that new maintainers are selected in a transparent and democratic way, with input from the entire community. It also helps maintain the health and sustainability of the project by ensuring that those who take on leadership roles are committed to its success and have the support of their peers.
Maintainers will be added to the GitHub @meshery/maintainers team, and made a GitHub maintainer of that team. They will be given write permission to the Meshery GitHub repository https://github.com/meshery/meshery repo.
Maintainership essentially involves more of the same of what you've already doing as a consistently engaged and impactful contributor, including regular attendance to project meetings, good-faith stewardship of the project and it’s external representation, encouragement of new contributors and so forth. Maintainers are generally saddled with the janitorial work that others are either not entrusted to do or don’t want to do (e.g. non-glamorous work like tests, release coordination, meeting prep and hosting, chasing down contributors to complete work).
The aforementioned responsibilities come with the following benefits:
Maintainers can voluntarily step down from their role at any time. If you decide to step down, please inform the other maintainers of your decision and explain your reasons. Before stepping down, please help identify and train your replacement(s), and ensure a seamless transition of responsibilities to prevent any disruption of work. When ready, you or another maintainer will submit a pull request removing your name from the MAINTAINERS.md file and into the list below. Another maintainer will adjust your various permissions / access levels to various project systems accordingly.
Any maintainer who is unresponsive or non-participatory (across the various forms of communication used by the project) for a period of two months forfeits maintainer privileges and resumes a contributor role. While much communication is asynchronous, maintainers are required to attend a minimum of one meeting a month in order facilitate high-fidelity, synchronous communication, which is necessary for the quality collaboration, conveyance of complex topics, and real-time advancement of the project.
Everyone is welcome to offer review on open pull requests. Maintainer approval or change requests count toward the requirement of approvals prior to pull request merge.