Discussed during 2018-07-18 meeting

We currently have two steering committee members assigned to review a given SIG's charter in a spreadsheet. Ideally one who is involved and familiar with the SIG, and one who is not.

We discussed turning this into an ongoing role to make sure we have clear points of contact going forward. Both for steering to reach out to sigs, and vice-versa.

I will implement this by adding fields to sigs.yaml and updating sig readmes to include this info. I will make sure verbiage about this ends up in the same document that describes other common sig roles.

/assign

Hey @kubernetes/steering-committee, in CNCF we review all of our project dependencies to ensure they comply with the CNCF IP Policy:

There have been a handful of dependencies that have been flagged as potential issues, usually a weak copyleft issue:

• heketi
• ratelimit
• yaml.v2
• hcl
• golang-lru
• dhcp4client
• influxdb (needs upgrade to switch out WTFPL subcomponent)

What would be the feasibility of switching these dependencies out or updating them to be compliant with the IP Policy? It would be great to put this on the SC agenda to discuss.

• Simplify the contributor ladder

• Clarify the process for approving/vetoing incubator projects and mitigate sponsor shopping
• Update incubator process to explain new GitHub organization strategy
• Clarify graduation process

• Project-wide communication requirements, processes, and mechanisms

Linux Foundation/CNCF use Condorcet/IRV for their elections. We use Condorcet/Schulze. We mostly picked Schulze because it's used by a bunch of OSS projects already and seemed like a good choice.

I don't think it would hurt for us to just line up with LF/CNCF on this so that we're consistent. Switching method is trivial in CIVS, this just involves PRing the documentation to mention IRV instead of Schulze.

Some information from @cra on the subject: http://www.daneckam.com/?p=374
Schulze information: https://en.wikipedia.org/wiki/Schulze_method

Need to resolve the disconnect between code organization (OWNERS, maintainers) and people organization (SIGs), as well as figure out how to enforce this programatically

• Improve/expand definition of members of standing
• Determine how this is maintained, especially during elections that require it

This issue is to help organize the work necessary to move SIG/WG charters forward.

Tracking spreadsheet that was the source for this issue

CHARTERS MERGED:

CHARTERS UNDER SC REVIEW:

CHARTERS MERGED WITHOUT/LIMITED SC REVIEW:

CHARTERS WE ARE HOLDING ON:

CHARTER ISSUES/RECOMMENDATIONS:

• SIG membership standardized
• Diversity and inclusion statement

TEMPLATE CHANGES REQUESTED:

• Clear direction on how unresponsive chairs are removed, especially when a low number exists - see this comment
• Separation of SIG and Sub-project roles - see this PR
• Something about how leadership lifecycle is managed - see this issue

SIGS TO BE SUNSET:

The PST wants to automate the rotation of people who handle the [email protected] reports.

We set out to have a goal of weekly rotations but without tooling and automation it isn't working well.

So, we are seeking a $540 budget for a yearly PagerDuty license. That is $9 * 12mo * 5 people.

We will start work on the tooling next week and will have a 14 day trial or something.

• Design, document, and communicate the escalation process

Per this thread in Kubernetes-Dev mailing list.

Why this should be reviewed by the steering committee:

Since etcd is not part of the Kubernetes codebase, but is widely considered a core component, it falls into a gray area as far as project governance is concerned.

Context: 20180718 https://youtu.be/I6BwkOA9dn4?t=23m51s

As SIG Cloud Provider takes shape, it has the potential to obviate existing cloud SIGs. Should that be mandated at some point, especially in light of cloud provider code being moved out of core?

• Provide suggested governance
• List minimum required content
• Find commonalities across the current charter pool and update templates accordingly

Now that the election is over for the KSC, the README should be refreshed with the members etc

• Determine how members of the Code of Conduct Committee should be selected
• Implement selection process
• Select members
• Ratify and communicate to the community about this

The CNCF has been piloting a security audit program for CNCF projects:

https://coredns.io/2018/03/15/cure53-security-assessment/
https://github.com/envoyproxy/envoy#security-audit
https://cure53.de/pentest-report_prometheus.pdf

The pilot has been successful and we are happy to start offering this to other CNCF projects that are interested. We would give preference to graduated projects first. After speaking with @bgrant0607 a bit he suggested making this a KSC topic, so here we are.

For 2019 we should keep consolidating the process of the elections. SC did most of this for 2018 but we were running into a deadline, so people have two documents that they have to refer to:

https://github.com/kubernetes/community/tree/master/events/elections/2018
https://github.com/kubernetes/steering/blob/master/elections.md

We should review and determine:

a) Specifically what should go in the overall steering election document.
b) Specifically decide what year-specific information should go in the voter guide.
c) Be more explicit about which steps are owned by SC and which steps are owned by the election officers.

It might also make sense to just move all the election documentation under steering so it's all in one place. Do they even need to be separate documents? etc. I'm mostly filing this so we remember to do it 1H 2019 so we don't run into a deadline.

• Committee decision-making process (e.g., modified lazy consensus seeking) and quorum requirement

I was watching a recording of the steering meeting yesterday, and tried to find the notes that were referenced during the meeting. I found a link in the README, but the bit.ly link appears to be broken - and is returning a 404: https://bit.ly/k8s-steering

Wasn't entirely sure how to report it, or what the appropriate link fix would be, so opening an issue here...

This comes from an email to Steering@

Hello Kubernetes maintainers,

I'm running the Linux Foundation's license scanning and analysis services for several LF projects. For CNCF's IP policy and its new license whitelist (approved at the May Governing Board meeting), going forward I'll be running and providing monthly scan reports for CNCF projects, including Kubernetes.

Attached are two spreadsheets showing the license notices found in the kubernetes and kubernetes-client orgs' code repos as of July 3. (Future results will be available through a web interface and in other file formats.) This report shows licenses actually contained in the source code repos, and does not address external dependencies pulled in at build-time or run-time.

Apache-2.0 files are under CNCF's project license, and many of the "Attribution" licenses will be auto-approved under CNCF's whitelist policy. For the remainder, I'll work with CNCF's IP Committee to review and discuss recommending approvals by the Governing Board.

In preparation for that, I have a few questions for you, focusing on the key findings. If you'd prefer that I submit issues in Github for these, I'm happy to do so -- just let me know. But for #1 and #2 in particular I wanted to raise these first with the maintainer list, in light of the particular license issues.

1. The component github.com/heketi/heketi is used in four repos. Heketi uses a mix of licenses, but the main issue is that files in heketi/pkg/utils/ can only be used under LGPL-3.0 or GPL-2.0, both of which are likely problematic here. Can the files in heketi/pkg/utils/ be removed, or replaced with an alternative library under a more permissive license?
   The repos are: kubernetes, minikube, autoscaler/cluster-autoscaler, and contrib/rescheduler

2. There are GPL-2.0 LICENSE text files in the github.com/docker/docker component, within the contrib/selinux-* subfolders in four repos. There is no corresponding code in these directories. Can these directories and LICENSE files be removed?
   The repos are: cloud-provider-aws, federation, kops and test-infra

3. The component github.com/juju/ratelimit is under LGPL-3.0 with a linking exception. It was replaced in the main kubernetes repo in #38320 to use golang.org/x/time/rate instead. juju/ratelimit is still present in several other kubernetes repos; can these be similarly updated to the alternate library?
   The repos are: autoscaler/addon-resizer, contrib (in diurnal, docker-micro-benchmark, election, keepalived-vip, scale-demo and service-loadbalancer), dashboard, dns, federation, frakti, heapster, kompose, kube-deploy, node-problem-detector, perf-tests, and test-infra.

4. The component gopkg.in/yaml.v2 used to have the same LGPL-3.0 license, but has now been updated in the kubernetes repo to a newer version with Apache-2.0. Several other repos still use the old version under LGPL-3.0; can these also be updated?
   The repos are: autoscaler/addon-resizer, contrib (in diurnal, docker-micro-benchmark, election, keepalived-vip, podex, scale-demo and service-loadbalancer), dashboard, federation, heapster, kube-deploy, node-problem-detector, perf-tests, publishing-bot and test-infra.

5. In minikube, there is a config file which states that it is part of systemd and is under LGPL-2.1. Most of the file is commented out. Is it necessary to distribute this file, or could it be obtained by the downstream user separately (along with systemd, which I assume we aren't distributing)?

6. In kops, /hooks/nvidia-bootstrap/README.md says that "Using this hook indicates that you agree to" a non-OSS license from NVIDIA. Is this intended to refer to software separately installed by the Dockerfile, rather than code in the kops repo itself? If so, I may propose a tweak to the language here.

7. In the translations/ folder in kubernetes, there are 12 files stating that "This file is distributed under the same license as the PACKAGE package." (e.g., here) Can these be corrected to refer to Kubernetes specifically?

8. In the kubernetes-client javascript repo, a package.json file was added stating that the kubernetes-client-typescript package is under the Unlicense. Can this be corrected to Apache-2.0?

Going forward I will likely have other suggestions and questions around licenses, but those above will help me to prepare Kubernetes for review and approval by the IP Committee / GB.

Thanks again for all your help, and please let me know if you have any questions. Best,
Steve

--
Steve Winslow
Director of Strategic Programs
The Linux Foundation
[email protected]

This is based on / inspired by a SIG Architecture proposal to expand SIG metadata and flesh out OWNERS

This is driven by a steering committee goal of ensuring that our organizational structure maps to our code structure.

Every part of the Kubernetes code and documentation should be owned by a Special Interest Group (SIG). However, many SIGs have multiple significant subprojects with distinct (though sometimes overlapping) sets of contributors and owners, who act as subproject’s technical leaders: responsible for vision and direction and overall design, choose/approve change proposal (KEP) approvers, field technical escalations, etc. We should formally recognize that.

For example, SIG Network potentially could be divided into multiple subprojects: pod networking (CNI, etc.), Service, Ingress, DNS, and Network policy. SIG Apps has the workload APIs, Helm, and Kompose. SIG Cluster Lifecycle has kubeadm, kops, kubespray, minikube, etc. SIG API machinery has apiserver, client libraries, API discovery and OpenAPI, CRD, API aggregation, and admission extension. In addition to Kubelet proper, SIG Node has multiple CRI implementations underway. Maybe some of these subprojects should be grouped, but hopefully you get the idea.

I'd like to start by implementing this concept in sigs.yaml. This ensures the information is machine-readable, generated README's contain human-readable information, and we start with a single source of truth.

Strawman:

• a sig may have N subprojects
• a subproject must have a name
• a subproject must have 1 - N OWNERS files associated with it
• the OWNERS files define the root of the repos/subdirectories owned by the subproject
• a subproject may have a description
• a subproject may have one or more meetings
• meetings can have different uris for video, agenda, recordings, etc.

Looking at SIG Apps as an example:

• A "Workloads API" subproject could potentially span multiple subdirs and repos
• A "Charts" subproject spans the kubernetes/charts repo
• A "Helm" subproject could potentially span kubernetes/helm and kubernetes-helm/* repos

Looking at SIG Contributor Experience as an example:

• A "Mentorship" subproject would own the docs in kubernetes/community that related to mentorship
• A "Community Management" subproject would own the docs in multiple subdirs of kubernetes/community

I am putting together an implementation based on this strawman with a total guess of single-repo subprojects based on first-pass by @bgrant0607, so we have a concrete example to iterate on. The intent isn't to voluntold SIG's into owning repos, but to identify where our gaps lie.

/sig contributor-experience
/sig apps
Since I mention you two as examples

/committee steering
/priority important-soon
/assign

From the mailing list:

"SIG Contributor Experience would like to apply for a repo as part of our "community" subproject. We are working on generating a contributor.k8s.io site that will basically take all the markdown in k/community and generate a nicer site for us to use instead of passing around raw github links.

Perhaps github.com/kubernetes-sigs/contributor-site with these owners: https://raw.githubusercontent.com/kubernetes/community/master/OWNERS

For reference here is the KEP for the contributor site: https://github.com/kubernetes/community/blob/master/keps/sig-contributor-experience/0005-contributor-site.md"

+1 from Sarah, Brian and Brandon as of 7/16/2018 ~ waiting for lazy consensus approval on 7/23/2018

@kujenga commented on Mon Jan 08 2018

There is an LGPL license for code that is vendored in client-go: https://github.com/kubernetes/client-go/blob/master/vendor/github.com/juju/ratelimit/LICENSE

It appears that this is inherited from the main Kubernetes repository: https://github.com/kubernetes/kubernetes/blob/master/vendor/github.com/juju/ratelimit/LICENSE

Does this not "infect" use of the code in this repository in some way? What compatibility is there with the Apache 2.0 license that this repository bears?

Edit: Apache lists incompatible licenses: http://www.apache.org/legal/resolved.html#category-x

@sttts commented on Mon Jan 22 2018

Can you move this discussion to #21 ?

@denismakogon commented on Wed Jan 24 2018

Okay, so, do we already know when the client would get rid of juju/ratelimit ?

@sttts commented on Wed Jan 24 2018

@denismakogon kubernetes/kubernetes#38320

@sttts commented on Wed Jan 24 2018

@denismakogon some hours after the upper PR is merged, you see it here.

@denismakogon commented on Wed Jan 24 2018

@sttts thanks!

• Identify who is responsible for evolving the governance going forward and how changes will be approved

• when does the steering committee engage the election officials? can we say July 1 every year is the date that steering kicks off election conversations?
• when/how/who does steering committee codify the eligible voter definition every year? ie - are you using devstats, whats the cut off number? will election officials have this information no later than August 1?
• who makes the announcements? blog, k-dev ml, k-dev slack, and Thursday Community Meeting (comm mtg is covered in docs and says SC but no other granularity)
• who lets the winners know if they are not already on SC?
• when and who PRs the winners into the SC README of listed members?
• when exactly does the term start and stop?

Hey @kubernetes/steering-committee, we are starting the process to graduate some projects (e.g., cncf/toc#69) in CNCF and would love to have Kubernetes be part of that process.

I've sketched out a rough doc that shows that kubernetes fulfills the requirements here: https://docs.google.com/document/d/18QORSz2_QzlFVDL86XzGXy0BwbO7LYsdSBraQ6iAGu0/edit#heading=h.hfdvv8nysu5h

I'd love consensus from the @kubernetes/steering-committee to move forward with this.

• build system (make, bazel, godep, etc.)
• util libraries
• Github org/repo management (e.g., dealing with Github changes, consistency across repos, etc.)
• Node controller
• kube-controller-manager binary
• hyperkube

Formalize the concept and governance model around sub-projects, then document and socialize them to the community.

Now that the KSC is formed, they should select a represented amongst themselves to be on the CNCF GB: https://github.com/cncf/foundation/blob/master/gb-developer-reps.md

Could this be done by the end of next month so the representative could join us at the next CNCF GB meeting in December at KubeCon/CNCon?

• Need to explicitly delegate powers to SIGs
• Document this and socialize with the community

• Determine how documentation policies are enforced with recommendations needed by SIG-Docs
• Integrate enforcement into the release process

• Do we need user groups?
• Do we need insurance?
• Do we need a policy similar to Apache's release policy?
• Do we need a Conflict of Interest policy?

Need to define:

• its scope (topics, subsystems, code repos and directories)
• responsibilities
• areas of authority
• how members and roles of authority/leadership are selected/granted
• how decisions are made
• how conflicts are resolved

• Develop processes to address staffing gaps (engineering, docs, test, release, ...)
• effort gaps (tragedy of the commons)
• expertise mismatches
• priority conflicts
• personnel conflicts

• Update docs to describe relationship with SIGs

Some CNCF members have higher maintenance legal departments and require a bit more documentation in repos regarding contributing criteria. For example, there is the Kubernetes Contributor Guide that mandates that the CNCF CLA be signed and seems to apply to all code, but has a big disclaimer at the top which makes some legal departments wary. Some of the repo’s have a CONTRIBUTING.md file with a clear process which is good, others point to the Contributor Guide which is okay but many others have no such file – for example:

https://github.com/kubernetes/apiserver
https://github.com/kubernetes/cloud-provider-aws
https://github.com/kubernetes/cloud-provider-gcp
https://github.com/kubernetes/cloud-provider-openstack
https://github.com/kubernetes/common
https://github.com/kubernetes/dashboard
https://github.com/kubernetes/examples
https://github.com/kubernetes/federation
https://github.com/kubernetes/gengo
https://github.com/kubernetes/kube-openapi
https://github.com/kubernetes/kube-state-metrics
https://github.com/kubernetes/kubernetes-anywhere
https://github.com/kubernetes/kubernetes-bootcamp
https://github.com/kubernetes/node-problem-detector
https://github.com/kubernetes/publishing-bot
https://github.com/kubernetes/release
https://github.com/kubernetes/repo-infra
https://github.com/kubernetes/test-infra
https://github.com/kubernetes/utils

Can we ensure that every proper Kubernetes project has a CONTRIBUTING.md with terms clearly spelled out?

Share CoC related historical data and have an open discussion to answer questions the CoCC may have for the steering committee.

Draft timeline:

• Election results announced - early Oct 2018? (‘t’)
• Open for votes - t-2 weeks?
• Announce who may vote (and allow exception applications) - t-4 weeks?
• Candidate bio distribution deadline - t-4 weeks?
• Candidate solicitation - t-6 weeks?
• Sounds like we need to kickstart the process ~early Aug (t-8 weeks).

Per Sarah Novotny:

We need to discuss the legal benefits of remaining on the CLA instead of moving to DCO. To get the expert perspective, I'd like to have one of our lawyers outline why Google is strongly supportive of CLAs.

Let's align on what makes a good charter using this issue and then make it a doc. cc/ @philips @pwittrock

• Document resources that the community has and make sure they have a home: releases, twitter handles, etc.

also, slack.

• Decide how/whether ecosystem subprojects (e.g., kops, helm) are governed differently
• Develop policies/procedures for donated code (e.g., helm, kubernetes-anywhere, kompose, kargo)

• Update the Code of Conduct Committee to a more recent version
• document enforcement
• broaden coverage beyond maintainers and committers
• handle coding activities and project/public spaces
• specify our own reporting path
• clarify the policy on employer notification and who else may be involved
• decide what should be shared with the accused

Discussed here

As per the email sent to kubernetes-dev[1], please create a SECURITY_CONTACTS
file.

The template for the file can be found in the kubernetes-template repository[2].
A description for the file is in the steering-committee docs[3], you might need
to search that page for "Security Contacts".

Please feel free to ping me on the PR when you make it, otherwise I will see when
you close this issue. :)

Thanks so much, let me know if you have any questions.

(This issue was generated from a tool, apologies for any weirdness.)

[1] https://groups.google.com/forum/#!topic/kubernetes-dev/codeiIoQ6QE
[2] https://github.com/kubernetes/kubernetes-template-project/blob/master/SECURITY_CONTACTS
[3] https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-template-short.md

• Fund-requesting and budget processes needs to be formalized and documented

Filing this now so we consider it for 2019. Right now the selection process is "steering committee selects election officers." Having 3 officers this year helped (instead of two) and I was thinking we should consider codifying it like this per election:

• One new member who has never served before.
• Two members who have served before.

In this way we always have one new person learning the process, and we keep 2 people with experience. Also consider enforcing one-company-rep-per-officer to keep it fresh.

Therefore one individual can serve 2 or 3 elections and we can keep a healthy rotation of people and affiliations.

https://youtu.be/BuJhzJriaNY?t=31m20s