Governance

The governance model adopted here is heavily influenced by a set of CNCF projects, especially drawing reference from Kubernetes governance. For similar structures some of the same wordings from kubernetes governance are borrowed to adhere to the originally construed meaning.

Principles

  • Open: KubeEdge is open source community.
  • Welcoming and respectful: See Code of Conduct.
  • Transparent and accessible: Work and collaboration should be done in public. Changes to the KubeEdge organization, KubeEdge code repositories, and CNCF related activities (e.g. level, involvement, etc) are done in public.
  • Merit: Ideas and contributions are accepted according to their technical merit and alignment with project objectives, scope and design principles.

Code of Conduct

KubeEdge follows the CNCF Code of Conduct. Here is an excerpt:

As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.

Community Membership

See community membership

Community Groups

Special Interest Groups (SIGs)

The KubeEdge 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 kubeedge 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 KubeEdge 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.

CLA

All contributors must sign the CNCF CLA, as described here.

Credits

Sections of this documents have been borrowed from Kubernetes governance.