added SIG Arch charter (#2804)

* added draft SIG Arch charter

* update link to subprojects

* changed to API definitions per lavalamp

* updated with Dims wording fix

* remove test file

* remove redundant reference to no TLs

* integrating bgrant feedback from PR

* fixed missing word

* Added to-do per quinton-hoole-2

* addressed final comments on out-of-scope items

1 files changed, 64 insertions, 38 deletions

diff --git a/sig-architecture/charter.md b/sig-architecture/charter.md
index 55214bab..066f0625 100644
--- a/sig-architecture/charter.md
+++ b/sig-architecture/charter.md
@@ -1,40 +1,66 @@
 # SIG Architecture Charter
 
-This charter is a WIP.
-
-The Architecture SIG maintains and evolves the design principles of
-Kubernetes, and provides a consistent body of expertise necessary to
-ensure architectural consistency over time.
-
-The scope covers issues that span all the system's components, how
-they fit together, how they interact, etc.
-
-Specific areas of focus include:
-
-* Defining the scope of the Kubernetes project
-  * [What is (and is not) Kubernetes](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)
-* Maintaining, evolving, and enforcing the deprecation policy
-  * [Deprecation policy](https://kubernetes.io/docs/reference/deprecation-policy/)
-* Documenting and evolving the system architecture
-  * [Kubernetes Design and Architecture](../contributors/design-proposals/architecture/architecture.md)
-* Defining and driving necessary extensibility points
-* Establishing and documenting design principles
-  * [Design principles](../contributors/design-proposals/architecture/principles.md)
-* Establishing and documenting conventions for system and user-facing APIs
-  * [API conventions](/contributors/devel/api-conventions.md)
-* Developing necessary technical review processes, such as the proposal and API review processes
-* Driving improvement of overall code organization, including github orgs and repositories
-* Educating approvers/owners of other SIGs (e.g., by holding office hours)
-
-Out of scope:
-* 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 and conventions.
-* [Release support policy](/contributors/design-proposals/release/versioning.md)
-  is owned by SIG Release
-
-TODO:
-* Formalize decision processes
-* Document initial reviewers and approvers
-* Clarify criteria for areas out of scope for the SIG
-* Document who owns client library, build, and release artifacts
-* Document who owns conformance definition, profiles, etc.
+This charter adheres to the conventions described in the [Kubernetes Charter README] and uses
+the Roles and Organization Management outlined in [sig-governance].
+
+## Scope
+
+The Architecture SIG maintains and evolves the design principles of Kubernetes, and provides a consistent body of expertise necessary to ensure architectural consistency over time.
+
+### In scope
+
+#### Code, Binaries, Docs, and Services
+
+- *Conformance test definitions*
+- *API definitions*
+- *Architectural renderings*
+- *API conventions*
+- *Design principles*
+- *Deprecation policy*
+
+#### Cross-cutting and Externally Facing Processes
+
+- API review process
+- Conformance test review and management
+- The Kubernetes Enhancement Proposal (KEP) process and KEP reviews
+- Design documentation management
+- Deprecation policy management
+- Architectural initiative backlog management
+
+### Out of scope
+
+- KEPs that do not have architectural implications or impact are managed by their respective sponsoring SIG(s)
+- The release enhancement delivery [process] that is part of the SIG-Release Release Team [subproject]
+
+## Roles and Organization Management
+
+This sig follows and adheres to the Roles and Organization Management outlined in [sig-governance]
+and opts-in to updates and modifications to [sig-governance].
+
+### Additional responsibilities of Chairs
+
+- Manage and curate the project boards associated with all sub-projects ahead of every SIG meeting so they may be discussed
+- Ensure the agenda is populated 24 hours in advance of the meeting, or the meeting is then cancelled
+- Report the SIG status at events and community meetings wherever possible
+- Actively promote diversity and inclusion in the SIG
+- Uphold the Kubernetes Code of Conduct especially in terms of personal behavior and responsibility
+
+### Deviations from [sig-governance]
+
+### Subproject Creation
+
+Federation of Subprojects as defined in [sig-governance]
+
+### To do
+
+- There remains lack of consensus in this SIG regarding the need for company and other diversity in the leadership of this SIG and it's subprojects, beyond what is contained in [sig-governance]. This still needs to be resolved and documented in this charter. Further details may be found [here].
+
+- It remains unspecified whether and how SIG-Architecture gets involved in resolving technical [conflicts] within and between other SIG's, and this SIG's sub-projects. This still needs to be resolved and documented in this charter.
+
+[sig-governance]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md
+[sig-subprojects]: https://github.com/kubernetes/community/blob/master/sig-architecture/README.md#subprojects
+[Kubernetes Charter README]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md
+[here]: https://docs.google.com/document/d/1TTcfvf8T_tBhGDm-wjgg31WrWjYg8IZEmo3b1mpUXh0/edit?usp=sharing
+[conflicts]: https://github.com/kubernetes/community/pull/2074#discussion_r184466503
+[process]: https://github.com/kubernetes/sig-release/blob/master/release-team/role-handbooks/enhancements/README.md
+[subproject]: https://github.com/kubernetes/sig-release/blob/master/release-team/README.md