- How are you doing with operational tasks in
sig-governance.md?
- Is your README accurate? have a CONTRIBUTING.md file?
- Yes, README.md is accurate
- We have a CONTRIBUTING.md
- All subprojects correctly mapped and listed in sigs.yaml?
- What’s your meeting culture? Large/small, active/quiet, learnings? Meeting notes up to date? Are you keeping
recordings up to date/trends in community members watching recordings?
- The main SIG meeting has ~10 people on average. Some projects like kubeadm have low attendance, while others like Cluster API have high attendance. Meeting notes usually are a best effort. We record all SIG meetings.
- Is your README accurate? have a CONTRIBUTING.md file?
- How does the group get updates, reports, or feedback from subprojects? Are there any springing up or being
retired? Are OWNERS.md files up to date in these areas?
- We do regular subproject updates as part of the main SIG call.
- We recently retired https://github.com/kubernetes/kube-deploy and https://github.com/kubernetes-retired/kube-aws.
- Keeping OWNERS files up-to-date falls under maintenance of subproject leads. We hope that they keep them up-to-date as they know their community better. We update OWNER files and send occasional reminders for that:
- Same question as above but for working groups.
- The WG Component Standard which we co-own with SIG API Machinery is looking for new leads. On private we proposed that we should ideally find new leads instead of disbanding the WG, but if no leads volunteer we are going to have to do that. The WG is not very active, due to the current leads being busy with other work.
- We do not own other WGs.
- When was your last monthly community-wide update? (provide link to deck and/or recording)
- Are all listed SIG leaders (chairs, tech leads, and subproject owners) active?
- For the SIG leads yes.
- For subproject owners, likely there are some inactive maintainers, but it’s up to the subproject to prune their OWNERs files.
- How do you measure membership? By mailing list members, OWNERs, or something else?
- Anyone can be considered a SIG member if they join the Zoom calls or general discussions regularly.
- In terms of repository scope - an active contributor with PRs / Issues / Reviews becomes eligible to be part of an OWNERS file.
- How does the group measure reviewer and approver bandwidth? Do you need help in any area now? What are you doing about it?
- For sub-projects, it’s up to the active subproject maintainers to allocate review resources.
- Some projects like etcdadm, cluster-addons and kubeadm are currently looking for more contributors.
- We use the common methods of “help-wanted” labels and announcing the request for help on slack / mailing list.
- For the main SIG (e.g. when reviewing KEPs) the lead who has the time usually reviews, but we try to notify everyone so that they can comment if they have the time too.
- Is there a healthy onboarding and growth path for contributors in your SIG?
What are some activities that the group does to encourage this? What programs are you participating in to grow contributors
throughout the contributor ladder?
- One of our methods is to just record onboarding videos / hold Zoom sessions discussing a certain problem / area:
- New contributors interested in such an areas should join these calls and ask questions.
- Most of our meetings have a dedicated slot for welcoming newcomers.
- What programs do you participate in for new contributors?
- We participated in Google Summer of code 2020 with the Cluster Addons project.
- Does the group have contributors from multiple companies/affiliations? Can end users/companies contribute in some way that
they currently are not?
- We have contributors from a number of different companies interested in Kubernetes:
- Everyone can contribute as long as they have the motivation and their ideas are good.
- Please include links to KEPs and other supporting information that will be beneficial to multiple types of community members.
- What are initiatives that should be highlighted, lauded, shout out, that your group is proud of? Currently underway?
What are some of the longer tail projects that your group is working on?
- We did a KEP to standardize how clusters define insecure local container registries:
- Cluster API has its own spin of the KEP process and has a number of interesting active proposals:
- Most of our subprojects have existed for a long time - including, kubeadm, kops, minikube, etc.
- Year to date KEP work review: What’s now stable? Beta? Alpha? Road to alpha?
- Only kubeadm features go through the Alpha->GA stages of the Kubernetes release process:
- Projects like kops, minikube, kubeadm, kubespray are mostly stable.
- Projects like Cluster API and etcdadm are alpha and moving towards graduation following a process similar to Kubernetes.
- What areas and/or subprojects does the group need the most help with?
- Here are a few picks from more to less:
- What's the average open days of a PR and Issue in your group? / what metrics does your group care about and/or measure?
- Our SIG is quite big and it depends on the subprojects.
- It’s up to the subproject to monitor the metrics they care about.
- For the SIG as a whole we track what tickets we have here: