The K8s Network Plumbing Working Group follows the example set out by the Kubernetes and wider CNCF communities. Governance of the NPWG is lightweight so that process doesn't impede contribution.
The intention is to provide a common ground for GitHub software repositories under https://github.com/k8snetworkplumbingwg. These repositories encompass the work that's being done across the working group. As the group grows in size and as the stakeholders diversify, having a solid framework for contribution should benefit the group as a whole.
Note: This document is adapted from an original proposal.
The Network Plumbing Working Group's goal is to advance vendor-neutral open source and open standards in regards to networking capabilities for workloads running in Kubernetes. This includes creation of specifications for technologies, the development & tooling of these vendor-neutral technologies, building reference implementations, creation of proof-of-concept technologies to help drive the discussion, and furthering the specifications and implementations of those specifications. As appropriate, these technologies should work towards integration into core technologies, such as Kubernetes.
The Network Plumbing Working Group is responsible for maintaining and updating the specifications we have created, as well as maintenance of software that is created by members and maintainers of the Network Plumbing Working Group.
Meetings are held bi-weekly. The agenda document which contains time and connection details is here.
For any action that requires a vote, quorum must be achieved. To achieve quorum, 3 or more members shall be available to vote, and there shall be no more than 50% representation among voters of members in employment of the same employer. In order to make changes to the governance document, there shall be 5 or more members available to vote and there shall be no more than 50% representation of members in employment of the same employer.
An organization owner must be present to decide if there is quorum to make a decision.
Active and archived repositories are listed in REPOSITORIES. This file has the form:
## ACTIVE REPOSITORIES
repo-one http://link-to-repo-one.com
repo-two http://link-to-repo-two.com
## ARCHIVED REPOSITORIES
repo-three http://link-to-repo-three.com
...
To begin, donate, or archive a repository a proposal is made at the NPWG community meeting. If the group approves the change a PR will be made to the REPOSITORIES file in the community repository. The PR will stay open until the next NPWG community meeting at which time it can be merged by another vote. This allows the wider community - including those who aren't able to attend the regular community meeting - to have their say on governance changes. Once the PR is merged it's the responsibility of an organization owner to reflect the changes in GitHub. This process is followed for adding, donating or archiving repositories.
Pull requests should be approved by 2 or more maintainers employed by distinct employers before being merged. Maintainers may approve their own pull requests, however these pull requests must also be reviewed and approved by one or more other maintainers.
There are four defined roles in the NPWG - two at the organization level and two at the repository level.
This is an owner of the NPWG organization as listed in the community OWNERS file. These people are responsible for the long term health of the project and day-to-day administrative tasks. An organization owner must be present at the NPWG community meeting to hold votes that require quorum - including those on changing OWNERS files and on adding or archiving repositories.
The group of all owners should not have more than 50% representation by a single organization. Owners are responsible for creating repositories as well as setting GitHub roles for maintainers. Owners must not delete, rename, make private, or transfer ownership of any repositories outside of the GitHub organization, nor take any other disruptive action without a vote during a bi-weekly meeting.
Anyone is free to contribute to the Network Plumbing Working Group at any time. Contribution to the working group happens across a number of vectors, which include but are not limited to: The Network Plumbing Working Group's Google Groups email list, bi-weekly meetings and GitHub. Any member of the group is invited to join the discussion, and to submit patches to GitHub.
A "member" of the Network Plumbing Working Group has the right to vote given any decision the group makes.
Members shall be documented in the community repository.
This is a person with Admin
rights in a GitHub repository. They are responsible for the long term health of a repository. They are also responsible for periodic administrative tasks such as reflecting changes in OWNERS file to the GitHub settings of a repository.
This is a person with Maintain
rights in a GitHub repository. They are responsible for the day-to-day health of a repository. Tasks expected from maintainers include issue triage, code reviews, PR approvals and attending relevant community meetings.
Adding a member can be done by opening a PR to MEMBERS in this repo. Other changes to project roles will be proposed at the NPWG community meeting. If the group approves the change a PR will be made to the OWNERS file of the relevant repository. The PR will stay open until the next NPWG community meeting at which time it can be merged by another vote. This allows the wider community - including those who aren't able to attend the regular community meeting - to have their say on governance changes. Once the PR is merged it's the responsibility of a repository admin or organization owner to reflect the changes in the GitHub project settings of the relevant repository. This process is followed for adding, updating or removing members from the project roles they hold.
The OWNERS file in this repository has the form:
# OWNERS
owner-one
...
Other repositories under the NPWG have OWNERS files of the form:
## ADMINS: People who control settings for the repo.
admin-one
...
## Maintainers: People who can merge code in this repo.
maintainer-one
maintainer-two
...