At the leadership summit a few weeks ago, I believe there was consensus that we should start an Architecture SIG. There were also discussions of Working Groups around extensibility and repo refactoring, but I'd like to fold that into SIG Architecture, since they are all related, and because I've been driving these areas, directly or indirectly, and there are only so many meetings I can attend.
This is the proposal for such a SIG, as the first step in the SIG creation procedure: https://github.com/kubernetes/community/blob/master/sig-governance.md#sig-creation-procecure Initial mission statement (thanks to Jaice): The SIG would be intended to guide the design principles of Kubernetes, as well as provide a consistent body of expertise necessary to ensure architectural consistency over time. The scope would cover the whole project -- issues that span/encompass all the components, how they fit together, how they interact, etc. But the SIG would not get involved with issues specific to a particular component or functional area, which would be the purview of some other SIG, except where they deviate from project-wide principles/conventions. The specific areas I propose are: Defining the scope of the Kubernetes project: - https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ - Ecosystem examples <https://docs.google.com/presentation/d/1oPZ4rznkBe86O4rPwD2CWgqgMuaSXguIBHIE7Y0TKVc/edit#slide=id.g21b1f16809_5_86> Documenting and evolving the system architecture: - https://github.com/kubernetes/community/blob/master/ contributors/design-proposals/architecture.md <https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture.md> - Kubernetes Architecture presentation <https://docs.google.com/presentation/d/1oPZ4rznkBe86O4rPwD2CWgqgMuaSXguIBHIE7Y0TKVc/edit#slide=id.p> - Kubernetes Architectural roadmap working document <https://docs.google.com/document/d/1VEzP20JvIKckPrGSs_R-D4vlwFzMAaqJd-9Lvfyi3jw/edit#heading=h.ub3h0cdur849> Defining and driving necessary extensibility points <https://docs.google.com/presentation/d/1oPZ4rznkBe86O4rPwD2CWgqgMuaSXguIBHIE7Y0TKVc/edit#slide=id.g21b1f16809_5_91> . Establishing and documenting design principles and conventions for the overall system and user-facing APIs: - https://github.com/kubernetes/community/blob/master/ contributors/design-proposals/principles.md <https://github.com/kubernetes/community/blob/master/contributors/design-proposals/principles.md> - https://github.com/kubernetes/community/blob/master/ contributors/devel/api-conventions.md <https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md> Note that the API conventions aren't part of API machinery because that SIG is about the mechanisms for building the apiservers, APIs, and client libraries, not the principles/conventions driving the design of the APIs and their contents. Driving improvement of overall code organization -- multiple repos, etc. Developing necessary review processes, such as the proposal and API review processes. Educating approvers/owners of other SIGs (e.g., by holding office hours). Suggested meeting day/time: Thursday @ 9am Pacific, before the community meeting, biweekly -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
