[RFC] SIG-Node initial charter

2 files changed, 222 insertions, 7 deletions

diff --git a/sig-node/README.md b/sig-node/README.md
index 6c82f228..5935b43f 100644
--- a/sig-node/README.md
+++ b/sig-node/README.md
@@ -77,19 +77,20 @@ Monitor these for Github activity if you are not a member of the team.
 <!-- BEGIN CUSTOM CONTENT -->
 ## Goals
 
-Topics include, but are not limited to:
+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
+* Node reliability (prooblem detection and remediation)
 * Node lifecycle management (with [sig-cluster-lifecycle](../sig-cluster-lifecycle))
-* Container runtimes: docker, [rkt](../sig-rktnetes), etc.
+* Container runtimes
+* Device management
 * Images, package management
-* Resource management (with [sig-scheduling](../sig-scheduling))
-* Issues related to monitoring (with [sig-instrumentation](../sig-instrumentation))
+* 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))
-* Kernel interactions (to a limited extent)
-* ...
+* 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
new file mode 100644
index 00000000..1ef64833
--- /dev/null
+++ b/sig-node/charter.md
@@ -0,0 +1,214 @@
+# SIG Node 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
+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)
+
+### 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