Kubernetes Bylaws #351
Description
I have been meaning to write some comments related to:
Specifically, I think that the Kubernetes projects needs "Bylaws". The Bylaws can encompass most of what is in the Governance being worked on, the Elders proposal and the Three branches.
As a member of the ASF and member of the Kubernetes project, I think that a middle ground can be found between clear Bylaws that show how the project is organized and governed and simple ways to take decisions without too much bureaucracy.
Couple general comments:
The Kubernetes Way in the Governance document is very close to the Apache Way. One item that is not there is the concept of "non affiliation". This means that people talk on behalf of themselves and do not represent corporate interest. Non-affiliation is useful to avoid perception that a project is not governed by companies. This helps build a true sense of community, where people's involvement is measured on merit.
Right now the community is fragmented between the mailing lists, the SIG, SLACK, stack overflow etc. Apache puts the emphasis on mailing lists. What happens on the mailing list is what happens in the community, it is where the community lives. It is where decisions are taken. Any meeting reports to the mailing lists for archiving, and further discussion from members who could not attend meetings. The emphasis is put on consensus.
A purely consensus driven project is arguably difficult to operate. I believe that we can find a good balance of consensus and benevolent dictator model.
As an Apache guy, I find kubernetes-dev surprisingly very low volume. And often decision or important discussions are happening out of band. It does not promote inclusion.
Github is not a great way to promote inclusion or bring attention to important proposals. If you are not tagged in an issue/PR you don't know what is happening. DISCUSS threads should be created on the proper mailing lists of each project/sub-project/incubator. If consensus is not reached then our technical leaders will break the ties.
Taking an approach that mimics the Apache structure we could organize the project with:
-
A Board (The Kubernetes board, similar to what is described in the Elders proposal)
-
The Members ( Could be the current set of Github Members)
-
The Committers ( Folks with write access to some repos in the kubernetes and kubernetes-incubator orgs)
-
The Contributors (Anyone involved in the project but without commit access yet).
-
The Incubator ( Set of projects in the kubernetes-incubator)
Basic working mechanisms would be:
- The Board is elected once a year by the members (could be initialized by the current root OWNERS in kubernetes/kubernetes )
- The members nominate new members once a year. new members get in via vote.
- Create "Project committees" per repo (e.g Helm Project committee). With a "Vice President" which report status to the Board. The PC of a repo is made of committers to that repo (could be mapped to Github sub team for initialization).
- The set of committers is made of the committers of all project committees. (not all would be members).
- "Promotion" is based on merit and committers get voted in after nomination from exiting PC members.
- The Incubator needs to be properly created with its own PC and Chair. Graduation needs to be a vote in the Incubator main mailing lists.
- Each project has a project-dev@ mailing list (we currently kind of have that, just needs to be cleaned up).
Once we have these basic mechanisms in place ( in the form of short/succint bylaws), agreed on by VOTE on kubernetes-dev, we can move towards implementing a clear leadership structure as highlighted in the "three branches" (which BTW would start differentiating with Apache).