Dear Kubernetes community and WG Component Standard,
Leigh and I have decided to move on as chairs of the Component Standard Working Group at the end of January 2021. We no longer have the bandwidth to drive significant progress on WG projects or vision, and we're looking for a path to more sustainable leadership in these areas.
We have reached out to other SIG leads and community leaders who have been involved with our projects or similar efforts in the past, but have not yet been able to find replacement chairs. We have found one individual who may be interested in helping with project management if we can find replacement chairs.
Now, we're asking the broader community if anyone is interested in stepping up to chair WG CS. We'd like at least two chairs, and they should have the experience with Kubernetes conventions, API design, and architecture, to guide decisions with respect to the cross-cutting concerns of the WG.
We think the WG has made some great progress and we still believe in the projects outlined in the founding KEP, particularly that we can and should have consistent and reusable ways of implementing and interfacing with core components in Kubernetes. Some of the things the WG has accomplished include:
Continued progress on migrating components to ComponentConfig, thanks to the efforts of many new contributors who helped out as part of our mentorship drive.
Implementing strict decoders for ComponentConfig types.
Adding test coverage for ComponentConfig types.
Progress toward generic ComponentConfig in controller-runtime.
Welcoming new members to the community via contributor onboarding and mentorship.
When the WG was more active, we had several ongoing discussions about future work, including how to implement ComponentConfig in kube-controller-manager and, more broadly, controller-runtime, and how kubeadm should deal with ComponentConfig, and there is still some active work in improving ComponentConfig, like solving instance-specific config.
Overall participation has dropped significantly in the second half of 2020. Part of this is natural, as contributors grow and move on to other work, part of it is the exceptionally stressful state of the world this year weighing on everyone, and part of it is that neither of us are able to put in the same level of effort to drive participation as we did in 2019.
We believe the projects the WG is focused on deserve active, focused leadership. We think there are two possible ways to achieve this:
Find replacement chairs for the WG that can commit to actively driving progress on WG projects.
Dissolve the WG and re-home projects in active SIGs that touch the same areas, such as sig-apimachinery, sig-cluster-lifecycle, and sig-architecture, and can commit to driving progress.
We still believe that these projects cut across several SIGs, and that a distinct forum for working on them is valuable if it can be made sustainable. So: If you're interested or know someone who would be a good leader in this space, we're interested in engaging and will consider nominating them as replacements. We'd like at least two chairs, and they should have the experience with Kubernetes conventions, API design, and architecture, to guide decisions with respect to the cross-cutting concerns of the WG.
If we can't find sustainable leadership for the WG, then we think the next best option is to move the projects somewhere that they can benefit from sustainable leadership. This is likely a mix of the Architecture, Cluster Lifecycle, and API Machinery SIGs (our stakeholder SIGs).
Our original goal was to complete a transition by the end of 2020, but given that nobody has self-nominated to lead the WG yet, we want to allow a little more time for members of the broader community to consider this role. If nobody has self-nominated by the end of January 2021, we will move forward with dissolving the WG and re-homing projects to other SIGs with more participation.
Leigh and I will both remain active in the community and will be around to help support this transition. I personally intend to continue mentoring 1-2 contributors that are interested in working on ComponentConfig (particularly the instance-specific config KEP). Leigh commits to additional support and mentorship and is currently driving work related to ComponentConfig in cluster-addons and kubeadm.
Our hope is to find a sustainable home for these projects and continue to help where we are able to.
Mike Taufen and Leigh Capili, WG Component Standard Chairs