Project: Meshery (Provisioning / Automation & Configuration)
File: 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 . 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: Have enabled 2FA on their GitHub account. Have joined the Meshery slack. Are actively contributing to the project. Examples include: opening issues providing feedback on the project engaging in discussions on issues, pull requests, Slack, etc. attending community meetings have a sponsoring Maintainer, who has agreed to sponsor their membership request The Meshery project consists of multiple repositories. Each repository is subject to the same governance model, but different maintainers and reviewers. See . Maintainers have write access to repositories. The current maintainers of a repo can be found in 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

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. 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. To do so they need to open an issue in meshery/meshery showing that they fill the above requirements. Sponsors express their support by adding `+1` as a comment. 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.