+1 Op donderdag 22 juni 2017 22:12:48 UTC+2 schreef Brian Grant: > > 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 > - 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/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.
