update per common charter template

2 files changed, 76 insertions, 212 deletions

diff --git a/sig-node/README.md b/sig-node/README.md
index 5935b43f..e1bde974 100644
--- a/sig-node/README.md
+++ b/sig-node/README.md
@@ -79,18 +79,21 @@ Monitor these for Github activity if you are not a member of the team.
 
 The following topics fall under scope of this SIG.
 
-* Kubelet related features (e.g. Pod lifecycle)
-* Node level performance and scalability (with [sig-scalability](../sig-scalability))
-* Node reliability (prooblem detection and remediation)
-* Node lifecycle management (with [sig-cluster-lifecycle](../sig-cluster-lifecycle))
-* Container runtimes
-* Device management
-* Images, package management
-* Host resource management (with [sig-scheduling](../sig-scheduling))
-* Hardware discovery
-* Issues related to node, pod, container monitoring (with [sig-instrumentation](../sig-instrumentation))
-* Node level security and Pod isolation (with [sig-auth](../sig-auth))
-* Host OS and/or kernel interactions (to a limited extent)
+- Kubelet and its features
+- Pod API and Pod behaviors (with [sig-architecture](../sig-architecture))
+- Node API (with [sig-architecture](../sig-architecture))
+- Node controller
+- Node level performance and scalability (with [sig-scalability](../sig-scalability))
+- Node reliability (problem detection and remediation)
+- Node lifecycle management (with [sig-cluster-lifecycle](../sig-cluster-lifecycle))
+- Container runtimes
+- Device management
+- Image management
+- Node-level resource management (with [sig-scheduling](../sig-scheduling))
+- Hardware discovery
+- Issues related to node, pod, container monitoring (with [sig-instrumentation](../sig-instrumentation))
+- Node level security and Pod isolation (with [sig-auth](../sig-auth))
+- Host OS and/or kernel interactions (to a limited extent)
 
 We also work closely with [sig-storage](../sig-storage) and [sig-network](../sig-network). As you can see, this is a very cross-functional team!
 <!-- END CUSTOM CONTENT -->
diff --git a/sig-node/charter.md b/sig-node/charter.md
index 1ef64833..4150b605 100644
--- a/sig-node/charter.md
+++ b/sig-node/charter.md
@@ -1,214 +1,75 @@
-# SIG Node Governance
+# SIG Node Charter
+
+This charter adheres to the conventions described in the [Kubernetes Charter README] and uses
+the Roles and Organization Management outlined in [sig-governance].
 
 ## Scope
 
 SIG Node is responsible for the components that support the controlled
 interactions between pods and host resources.  We manage the lifecycle of pods
 that are scheduled to a node.  We focus on enabling a broad set of workload
-types, including hardware and performance sensitive workloads.  We maintain
+types, including workloads with hardware specific or performance sensitive requirements.  We maintain
 isolation boundaries between pods on a node, as well as the pod and the host.  We
 aim to continuously improve node reliability.
 
 ### In scope
 
-The following topics fall under ownership of this SIG.
-
-* Kubelet related features (e.g. Pod lifecycle)
-* Node level performance and scalability (with [sig-scalability](../sig-scalability))
-* Node reliability (prooblem detection and remediation)
-* Node lifecycle management (with [sig-cluster-lifecycle](../sig-cluster-lifecycle))
-* Container runtimes
-* Device management
-* Images, package management
-* Host resource management (with [sig-scheduling](../sig-scheduling))
-* Hardware discovery
-* Issues related to node, pod, container monitoring (with [sig-instrumentation](../sig-instrumentation))
-* Node level security and Pod isolation (with [sig-auth](../sig-auth))
-* Host OS and/or kernel interactions (to a limited extent)
+SIG [readme]
+
+#### Code, Binaries and Services
+
+- Kubelet and its features
+- Pod API and Pod behaviors (with [sig-architecture](../sig-architecture))
+- Node API (with [sig-architecture](../sig-architecture))
+- Node controller
+- Node level performance and scalability (with [sig-scalability](../sig-scalability))
+- Node reliability (problem detection and remediation)
+- Node lifecycle management (with [sig-cluster-lifecycle](../sig-cluster-lifecycle))
+- Container runtimes
+- Device management
+- Image management
+- Node-level resource management (with [sig-scheduling](../sig-scheduling))
+- Hardware discovery
+- Issues related to node, pod, container monitoring (with [sig-instrumentation](../sig-instrumentation))
+- Node level security and Pod isolation (with [sig-auth](../sig-auth))
+- Host OS and/or kernel interactions (to a limited extent)
+
+#### Cross-cutting and Externally Facing Processes
+
+- CRI [validation] and [testing policy]
+- Node [test grid] and [perf dashboard]
 
 ### Out of scope
 
-The following topics are out of the scope of this SIG
-
-* network management
-* persistent storage management
-
-## Roles
-
-Membership for roles tracked in: [OWNERS]
-
-- **Chairs**
-  - Run operations and processes governing the SIG
-  - *MUST* remain active in the role and are  removed from the position if they
-    are unresponsive for > 3 months and *MAY* be removed if not proactively
-    working with other chairs to fulfill responsibilities.  To remove an
-    inactive chair, a majority vote from existing chairs should occur. If a
-    [super-majority] is not possible, the [steering-committee] may sponsor
-    removal.
-  - *MAY* declare an intention to take sabbatical for no more than 3 months in a
-    calendar year.  Chairs should notify existing chairs of their intent, and
-    absent at least 2 remaining chairs, *MUST* nominate a temporary replacement
-    from the existing set of technical leads during this period.
-  - *SHOULD* represent a diverse set of organizations.  This is predicated on
-    interest in the role from multiple organizations with qualified candidates.
-    Qualification is measured by existing chairs and *SHOULD* be supported by a
-    majority of SIG Members under [lazy-consensus].
-  - *MAY* decide to step down at any time and propose a replacement.  Use lazy
-    consensus amongst chairs with fallback on majority vote to accept proposal.
-    This *SHOULD* be supported by a majority of SIG Members.
-  - *MAY* select additional chairs through a [super-majority] vote amongst
-    chairs.  This *SHOULD* be supported by a majority of SIG Members.
-  - Number: 1-3
-  - Defined in [sigs.yaml]
-
-- **Technical Leads**
-  - Technical leads seeded by legacy SIG chairs from subproject owners
-  - Establish new subprojects
-  - Decommission existing subprojects  
-  - Sponsor working groups
-  - End of life working groups
-  - *MUST* ensure that all areas of the SIG (including those that fall outside
-    subprojects) have active owners.
-  - *MAY* set SIG milestone priorities.
-  - *SHOULD* act as an escalation point for technical disputes in subprojects.
-  - *MUST* resolve issues impacting multiple subprojects in the SIG.
-  - *SHOULD* meet or communicate regularly enough to ensure they are aligned.
-    Decisions made by technical leads should be consistent across the SIG. If
-    technical leads are providing inconsistent direction, then they *MUST* align
-    themselves.
-  - *MAY* select additional tech leads through a [super-majority] vote amongst
-    tech leads and chairs.  This *SHOULD* be supported by a majority of SIG
-    Members under [lazy-consensus].
-  - *SHOULD* represent a diverse set of organizations.  This is predicated on
-    interest in the role from multiple organizations with qualified candidates.
-  - *MUST* remain active in the role and are automatically removed from the
-    position if they are unresponsive for > 3 months and *MAY* be removed if not
-    proactively working with other technical leads to fulfill responsibilities.
-    Removal of a technical lead requires [super-majority] vote amongst tech
-    leads and chairs.
-  - *MAY* declare an intention to take sabbatical for no more than 3 months in a
-    calendar year.  Chairs should notify existing chairs of their intent, and
-    absent at least 2 remaining chairs, *MUST* nominate a temporary replacement
-    from the existing set of technical leads during this period.    
-  - Technical Leads *SHOULD* represent a diverse set of organizations.  This is
-    predicated on interest in the role from multiple organizations with
-    qualified candidates.
-  - *SHOULD* have a record of consistent solid technical judgement and
-    leadership over a sustained period especially over areas for which they are
-    the de-facto lead
-  - Number: 3-7
-  - Defined in [sigs.yaml] and [OWNERS] files
-
-- **Subproject Owners**
-  - Scoped to a subproject defined in [sigs.yaml]
-  - Seed subproject owners *MAY* include initial proposal author(s) and/or Tech
-    Leads
-  - *MUST* be an escalation point for technical decisions and failing or flaky
-    tests in the subproject
-  - *MUST* proactively maintain the subproject health and status or delegate
-    this responsibility. For actively developed projects, this *SHOULD* include
-    setting milestone priorities, tracking release bits, and ensure adequate
-    test coverage. For maintenance mode projects, this *SHOULD* include
-    maintaining test health and ensuring compatibility with new features.
-  - *MUST* remain active in the role and are automatically removed from the
-    position if they are unresponsive for > 3 months.
-  - *MAY* declare an intention to take sabbatical for no more than 3 months in a
-    calendar year.  Should notify existing owners of their intent, and *MAY*
-    nominate a temporary replacement from the existing set of owners during this
-    period.
-  - *SHOULD* have a record of consistent solid technical judgement over a
-    sustained period, especially over areas for which they are the owner
-  - *MAY* be removed if not proactively working with other Subproject Owners to
-    fulfill responsibilities.
-  - *MAY* decide to step down at any time and propose a replacement.  Use
-    [lazy-consensus] amongst subproject owners with fallback on majority vote to
-    accept proposal.  This *SHOULD* be supported by a majority of subproject
-    contributors (those having some role in the subproject).
-  - *MAY* select additional subproject owners through a [super-majority] vote
-    amongst subproject owners.  This *SHOULD* be supported by a majority of
-    subproject contributors (through [lazy-consensus] with fallback on voting).
-  - *SHOULD* work to ensure technical excellence within area
-    - actively work to reduce complexity of the area
-    - define general acceptance criteria for work as needed (code, test,
-      documentation guidelines, etc)
-    - consider cross-project interactions in technical decisions
-    - prioritize urgent issues appropriately (e.g. addressing critical bugs,
-      security vulnerabilities, or test failures)
-  - Number: 1-7 per subproject (depending on size and scope)
-  - Defined in [sigs.yaml] [OWNERS] files
-
-- Members
-  - *MUST* maintain health of at least one subproject or the health of the SIG
-  - *MUST* show sustained contributions to at least one subproject or to the SIG
-  - *SHOULD* hold some documented role or responsibility in the SIG and / or at
-    least one subproject (e.g. reviewer, approver, etc)
-  - *MAY* build new functionality for subprojects
-  - *MAY* participate in decision making for the subprojects they hold roles in
-  - *SHOULD* include all reviewers and approvers in [OWNERS] files for
-    subprojects
-  - *MUST* remain active in the role and may be removed from the position if
-    they are unresponsive for > 1 year.
-  - *MAY* be removed if not proactively working with other Subproject Owners to
-    fulfill responsibilities.
-
-## Organizational management
-
-- SIG meets weekly on [zoom] with [agenda in meeting notes]
-  - *SHOULD* be facilitated by chairs unless delegated to specific Members
-- SIG overview and deep-dive sessions organized for Kubecon
-  - *SHOULD* be organized by chairs unless delegated to specific Members
-
-- Contributing instructions defined in the SIG CONTRIBUTING.md
-
-### Project management
-
-#### Subproject creation
-
-- Subprojects *MAY* be created by [KEP] proposal and *MUST* be approved by at
-  least 1 tech lead, and accepted by [lazy-consensus] with fallback on majority
-  vote of SIG Technical Leads.  The result *SHOULD* be supported by the majority
-  of SIG members.
-  - KEP *MUST* establish subproject owners
-  - [sigs.yaml] *MUST* be updated to include subproject information and [OWNERS]
-    files with subproject owners
-  - Where subprojects processes differ from the SIG, they must document how
-    - e.g. if subprojects release separately - they must document how release
-      and planning is performed
-  - Subprojects may not be seeded from existing repositories pending CNCF
-    process definition
-
-### Technical processes
-
-Subprojects of the SIG *MUST* use the following processes unless explicitly
-following alternatives they have defined.
-
-- Proposing and making decisions
-  - Proposals *SHOULD* be sent as [KEP] PRs and published to
-    [kubernetes-sig-node] as an announcement
-  - Proposals *MUST* be presented and discussed in at least 1 SIG node meeting
-    - If the authors are unable to attend, another community member can be found
-      to champion the proposal.
-  - Proposals *SHOULD* follow [KEP] decision making process
-    - For proposed extensions to a subproject, the subproject *MUST* be
-      identified in the KEP, and approvers *MUST* include subproject owners
-
-- Test health
-  - Canonical health of code published to [testgrid]
-  - Consistently broken tests automatically send an alert to
-    [kubernetes-sig-node-test-failures]
-  - SIG members are responsible for responding to broken tests alert.  PRs that
-    break tests should be rolled back if not fixed within 1 business day.
-  - Test dashboard checked and reviewed at start of each SIG meeting.  Owners
-    assigned for any broken tests and followed up during the next SIG meeting.
-
-[steering-committee]: https://github.com/kubernetes/community/blob/master/committee-steering/OWNERS
-[lazy-consensus]: http://communitymgt.wikia.com/wiki/Lazy_consensus
-[super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote
-[KEP]: https://github.com/kubernetes/community/blob/master/keps/0000-kep-template.md
-[sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml
-[OWNERS]: https://github.com/kubernetes/community/blob/master/sig-auth/OWNERS
-[agenda and meeting notes]: https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit
-[zoom]: https://zoom.us/j/4799874685
-[testgrid]: https://k8s-testgrid.appspot.com/sig-node#Summary
-[kubernetes-sig-node]: https://groups.google.com/forum/#!forum/kubernetes-sig-node
-[kubernetes-sig-node-test-failures]: https://groups.google.com/forum/#!forum/kubernetes-sig-node-test-failures
\ No newline at end of file
+- network management ([sig-network](../sig-network))
+- persistent storage management ([sig-storage](../sig-storage))
+
+## Roles and Organization Management
+
+This sig 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
+
+- Technical leads seeded by legacy SIG chairs from existing subproject owners
+
+### Additional responsibilities of Tech Leads
+
+None
+
+### Deviations from [sig-governance]
+
+None
+
+### Subproject Creation
+
+SIG Technical Leads
+
+
+[validation]: https://github.com/kubernetes/community/blob/master/contributors/devel/cri-validation.md
+[testing policy]: https://github.com/kubernetes/community/blob/master/contributors/devel/cri-testing-policy.md
+[test grid]: https://k8s-testgrid.appspot.com/sig-node#Summary
+[perf dashboard]: http://node-perf-dash.k8s.io/#/builds
+[sig-governance]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md
+[readme]: https://github.com/kubernetes/community/tree/master/sig-node
+[Kubernetes Charter README]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md
\ No newline at end of file