社区治理
Principles
- Open: Kmesh is open source community.
- Neutral: Kmesh is neutral in determining the various operating systems supported.
- Transparent and accessible: Work and collaboration should be done in public. Changes to the Kmesh organization, Kmesh code repositories.
- Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, scope and design principles.
Community Membership
Community Groups
Special Interest Groups (SIGs)
The Kmesh project is organized primarily into Special Interest Groups, or SIGs. Each SIG is comprised of individuals from multiple companies and organizations, with a common purpose of advancing the project with respect to a specific topic.
The goal is to enable a distributed decision structure and code ownership, as well as providing focused forums for getting work done, making decisions, and on-boarding new Contributors. Every identifiable part of the project(e.g. repository, subdirectory, API, test, issue, PR) is intended to be owned by some SIG.
SIG Chairs
SIGs must have at least one, and may have up to two SIG chairs at any given time. SIG chairs are intended to be organizers and facilitators, responsible for the operation of the SIG and for communication and coordination with the other SIGs, and the broader community.
SIG Charter
Each SIG must have a charter that specifies its scope (topics, sub-systems, code repos and directories), responsibilities, and areas of authority, how members and roles of authority/leadership are selected/granted, how decisions are made, and how conflicts are resolved.
SIGs should be relatively free to customize or change how they operate, within some broad guidelines and constraints imposed by cross-SIG processes (e.g., the release process) and assets (e.g., the Kmesh repo).
A primary reason that SIGs exist is as forums for collaboration. Much work in a SIG should stay local within that SIG. However, SIGs must communicate in the open, ensure other SIGs and community members can find meeting notes, discussions, designs, and decisions, and periodically communicate a high-level summary of the SIG’s work to the community. SIGs are also responsible to:
- Meet regularly, at least monthly
- Keep up-to-date meeting notes, linked from the SIG’s page in the community repo
- Announce meeting agenda and minutes after each meeting, on the Kmesh mailing list and/or slack or other channel.
- Ensure the SIG’s decision making is archived somewhere public
- Report activity in overall community meetings
- Participate in release planning meetings, retrospective, etc (if relevant)
- Actively triage issues, PRs, test failures, etc. related to code and tests owned by the SIG
- Use the above forums as the primary means of working, communicating, and collaborating, as opposed to private emails and meetings.
Credits
Sections of this documents have been borrowed from Kubernetes governance.