Skip to content

Latest commit

 

History

History
51 lines (30 loc) · 4.33 KB

GOVERNANCE.md

File metadata and controls

51 lines (30 loc) · 4.33 KB

Meshery Governance

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.

Contributors

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:

GitHub Project Administration

  • 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

Maintainership

The Meshery project consists of multiple repositories. Each repository is subject to the same governance model, but different maintainers and reviewers. See Maintainer Teams.

Maintainers

Maintainers have write access to repositories. 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).

Maintainer Teams

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.

Becoming a Maintainer

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.

Emeritus Maintainers

Abandonment of Role

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.

Reviewers

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.