diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES
index 0240d7406d0..5cd72ac8084 100644
--- a/OWNERS_ALIASES
+++ b/OWNERS_ALIASES
@@ -137,6 +137,11 @@ aliases:
   wg-kubeadm-adoption-leads:
     - luxas
     - justinsb
+  wg-lts-leads:
+    - tpepper
+    - imkin
+    - quinton-hoole-2
+    - youngnick
   wg-machine-learning-leads:
     - vishh
     - kow3ns
diff --git a/sig-list.md b/sig-list.md
index 98fb9533147..999cd862af4 100644
--- a/sig-list.md
+++ b/sig-list.md
@@ -64,6 +64,7 @@ When the need arises, a [new SIG can be created](sig-creation-procedure.md)
 |[IoT Edge](wg-iot-edge/README.md)||* [Cindy Xing](https://github.com/cindyxing), Huawei<br>* [Dejan Bosanac](https://github.com/dejanb), Red Hat<br>* [Preston Holmes](https://github.com/ptone), Google<br>* [Steve Wong](https://github.com/cantbewong), VMWare<br>|* [Slack](https://kubernetes.slack.com/messages/wg-iot-edge)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-wg-iot-edge)|* Regular WG Meeting: [Wednesdays at 17:00 UTC (every four weeks)](https://docs.google.com/document/d/1FQx0BPlkkl1Bn0c9ocVBxYIKojpmrS1CFP5h0DI68AE/edit)<br>* APAC WG Meeting: [Wednesdays at 5:00 UTC (every four weeks)](https://docs.google.com/document/d/1FQx0BPlkkl1Bn0c9ocVBxYIKojpmrS1CFP5h0DI68AE/edit)<br>
 |[K8s Infra](wg-k8s-infra/README.md)|* Architecture<br>* Contributor Experience<br>* Release<br>* Testing<br>|* [Davanum Srinivas](https://github.com/dims), Huawei<br>* [Aaron Crickenberger](https://github.com/spiffxp), Google<br>|* [Slack](https://kubernetes.slack.com/messages/wg-k8s-infra)<br>* [Mailing List](https://groups.google.com/forum/#!forum/wg-k8s-infra)|* Regular WG Meeting: [Wednesdays at 8:30 PT (Pacific Time) (bi-weekly)](https://docs.google.com/document/d/1FQx0BPlkkl1Bn0c9ocVBxYIKojpmrS1CFP5h0DI68AE/edit)<br>
 |[Kubeadm Adoption](wg-kubeadm-adoption/README.md)||* [Lucas Käldström](https://github.com/luxas), Luxas Labs (occasionally contracting for Weaveworks)<br>* [Justin Santa Barbara](https://github.com/justinsb)<br>|* [Slack](https://kubernetes.slack.com/messages/sig-cluster-lifecycle)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle)|* Regular WG Meeting: [Tuesdays at 18:00 UTC (bi-weekly)](https://docs.google.com/document/d/1FQx0BPlkkl1Bn0c9ocVBxYIKojpmrS1CFP5h0DI68AE/edit)<br>
+|[LTS](wg-lts/README.md)|* API Machinery<br>* CLI<br>* Node<br>|* [Tim Pepper](https://github.com/tpepper), VMware<br>* [Dhawal Yogesh Bhanusali](https://github.com/imkin), VMware<br>* [Quinton Hoole](https://github.com/quinton-hoole-2), Huawei<br>* [Nick Young](https://github.com/youngnick), Atlassian<br>|* [Slack](https://kubernetes.slack.com/messages/wg-lts)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-wg-lts)|* Regular WG Meeting: [Tuesdays at 09:00 PT (Pacific Time) (bi-weekly)](https://docs.google.com/document/d/1FQx0BPlkkl1Bn0c9ocVBxYIKojpmrS1CFP5h0DI68AE/edit)<br>
 |[Machine Learning](wg-machine-learning/README.md)||* [Vishnu Kannan](https://github.com/vishh), Google<br>* [Kenneth Owens](https://github.com/kow3ns), Google<br>* [Balaji Subramaniam](https://github.com/balajismaniam), Intel<br>* [Connor Doyle](https://github.com/ConnorDoyle), Intel<br>|* [Slack](https://kubernetes.slack.com/messages/wg-machine-learning)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-wg-machine-learning)|* Regular WG Meeting: [Thursdays at 13:00 PT (Pacific Time) (biweekly)](https://docs.google.com/document/d/1FQx0BPlkkl1Bn0c9ocVBxYIKojpmrS1CFP5h0DI68AE/edit)<br>
 |[Multitenancy](wg-multitenancy/README.md)||* [David Oppenheimer](https://github.com/davidopp), Google<br>* [Jessie Frazelle](https://github.com/jessfraz), Microsoft<br>|* [Slack](https://kubernetes.slack.com/messages/wg-multitenancy)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-wg-multitenancy)|* Regular WG Meeting: [Wednesdays at 11:00 PT (Pacific Time) (biweekly)](https://docs.google.com/document/d/1FQx0BPlkkl1Bn0c9ocVBxYIKojpmrS1CFP5h0DI68AE/edit)<br>
 |[Policy](wg-policy/README.md)||* [Howard Huang](https://github.com/hannibalhuang), Huawei<br>* [Torin Sandall](https://github.com/tsandall), Styra<br>* [Yisui Hu](https://github.com/easeway), Google<br>* [Erica von Buelow](https://github.com/ericavonb), Red Hat<br>* [Michael Elder](https://github.com/mdelder), IBM<br>|* [Slack](https://kubernetes.slack.com/messages/wg-policy)<br>* [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-wg-policy)|* Regular WG Meeting: [Wednesdays at 16:00 PT (Pacific Time) (weekly)](https://docs.google.com/document/d/1FQx0BPlkkl1Bn0c9ocVBxYIKojpmrS1CFP5h0DI68AE/edit)<br>
diff --git a/sigs.yaml b/sigs.yaml
index 8babc2f0f3a..a8a7a3f8c40 100644
--- a/sigs.yaml
+++ b/sigs.yaml
@@ -2203,6 +2203,50 @@ workinggroups:
     contact:
       slack: sig-cluster-lifecycle
       mailing_list: https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle
+  - name: LTS
+    dir: wg-lts
+    mission_statement: >
+      Answer the question: Does Kubernetes need a longer support
+      term? If yes, figure out what that looks like for Kubernetes
+      and propose this to the rest of the project. If no, figure
+      out how to help end users cope with this and propose that to
+      the rest of the project. If a proposal is accepted, the working
+      group's mission will change to implement it.
+
+      The working group is sponsored by SIG Release, but has the
+      potential to span almost all SIGs.  For more background see
+      the [WG formation proposal](https://docs.google.com/presentation/d/1-Z-mUNIs3mUi7AdP1KwoAVNviwKrCoo3lxMb5wzCWbk/edit?usp=sharing).
+    charter_link: charter.md
+    stakeholder_sigs:
+    - API Machinery
+    - CLI
+    - Node
+    leadership:
+      chairs:
+      - name: Tim Pepper
+        github: tpepper
+        company: VMware
+      - name: Dhawal Yogesh Bhanusali
+        github: imkin
+        company: VMware
+      - name: Quinton Hoole
+        github: quinton-hoole-2
+        company: Huawei
+      - name: Nick Young
+        github: youngnick
+        company: Atlassian
+    meetings:
+    - description: Regular WG Meeting
+      day: Tuesday
+      time: "09:00"
+      tz: "PT (Pacific Time)"
+      frequency: bi-weekly
+      url: https://docs.google.com/document/d/1FQx0BPlkkl1Bn0c9ocVBxYIKojpmrS1CFP5h0DI68AE/edit
+      archive_url: https://docs.google.com/document/d/1J2CJ-q9WlvCnIVkoEo9tAo19h08kOgUJAS3HxaSMsLA/edit?usp=sharing
+      recordings_url:
+    contact:
+      slack: wg-lts
+      mailing_list: https://groups.google.com/forum/#!forum/kubernetes-wg-lts
   - name: App Def
     dir: wg-app-def
     mission_statement: >
diff --git a/wg-lts/README.md b/wg-lts/README.md
new file mode 100644
index 00000000000..e98381d5d12
--- /dev/null
+++ b/wg-lts/README.md
@@ -0,0 +1,46 @@
+<!---
+This is an autogenerated file!
+
+Please do not edit this file directly, but instead make changes to the
+sigs.yaml file in the project root.
+
+To understand how this file is generated, see https://git.k8s.io/community/generator/README.md
+--->
+# LTS Working Group
+
+Answer the question: Does Kubernetes need a longer support term? If yes, figure out what that looks like for Kubernetes and propose this to the rest of the project. If no, figure out how to help end users cope with this and propose that to the rest of the project. If a proposal is accepted, the working group's mission will change to implement it.
+The working group is sponsored by SIG Release, but has the potential to span almost all SIGs.  For more background see the [WG formation proposal](https://docs.google.com/presentation/d/1-Z-mUNIs3mUi7AdP1KwoAVNviwKrCoo3lxMb5wzCWbk/edit?usp=sharing).
+
+The [charter](charter.md) defines the scope and governance of the LTS Working Group.
+
+## Stakeholder SIGs
+* SIG API Machinery
+* SIG CLI
+* SIG Node
+
+## Meetings
+* Regular WG Meeting: [Tuesdays at 09:00 PT (Pacific Time)](https://docs.google.com/document/d/1FQx0BPlkkl1Bn0c9ocVBxYIKojpmrS1CFP5h0DI68AE/edit) (bi-weekly). [Convert to your timezone](http://www.thetimezoneconverter.com/?t=09:00&tz=PT%20%28Pacific%20Time%29).
+  * [Meeting notes and Agenda](https://docs.google.com/document/d/1J2CJ-q9WlvCnIVkoEo9tAo19h08kOgUJAS3HxaSMsLA/edit?usp=sharing).
+
+## Organizers
+
+* Tim Pepper (**[@tpepper](https://github.com/tpepper)**), VMware
+* Dhawal Yogesh Bhanusali (**[@imkin](https://github.com/imkin)**), VMware
+* Quinton Hoole (**[@quinton-hoole-2](https://github.com/quinton-hoole-2)**), Huawei
+* Nick Young (**[@youngnick](https://github.com/youngnick)**), Atlassian
+
+## Contact
+* [Slack](https://kubernetes.slack.com/messages/wg-lts)
+* [Mailing list](https://groups.google.com/forum/#!forum/kubernetes-wg-lts)
+
+<!-- BEGIN CUSTOM CONTENT -->
+
+## Goals
+* Evaluate user/operator sentiment and support requirements.
+* Foster cross-vendor, subject matter expert led bug and security fixes for support streams.  The project is more sustainable when this work is done once authoritatively in shared support branch(es), versus in parallel at all vendors.
+* Increase developer visibility on cross-release compatibility and stability issues.
+* If appropriate based on analysis, draft LTS KEP for SIG Release to operationalize.
+
+We are an open and active working group, and we always welcome new additions!
+
+<!-- END CUSTOM CONTENT -->
diff --git a/wg-lts/charter.md b/wg-lts/charter.md
new file mode 100644
index 00000000000..2c81e4453dc
--- /dev/null
+++ b/wg-lts/charter.md
@@ -0,0 +1,137 @@
+# WG LTS Charter
+This charter adheres to the [wg-governance] guidance, as well as
+adheres to the general conventions described in the [Kubernetes
+Charter README] and the Roles and Organization Management outlined
+in [sig-governance], where applicable to a Working Group.
+
+## Scope
+The Long Term Support Working Group (WG LTS) is organized with the
+goal of provide a cross SIG location for focused collection of
+stakeholder feedback regarding the support stance of Kubernetes
+project in order to inform proposals for support improvements.
+
+"WG LTS" is simply shorter than "WG To LTS Or Not To LTS" or "WG
+What Are We Releasing And Why And How Is It Best Integrated, Validate,
+And Supported", but should NOT be read in that shortness to imply
+establishing a traditional LTS scheme (multi-year support; upgrade
+from LTS N to N+1, skipping intermediate versions) is the foregone
+conclusion of the WG.
+
+### In Scope
+* What is a Kubernetes release?
+* What is a supported release?  Ie: Stable branches to which critical fixes are backported.
+ * Number of community supported branches.
+ * Duration of community support per supported branch.
+ * Upgrade path considerations.
+* Costs of Kubernetes releases in terms of:
+ * Infrastructure
+ * People
+* Process: how/where code changes are backported to community supported branches.
+
+### Out of Scope
+* The lifecycle of projects outside of the Kubernetes org.
+* Technical and end-user support:  The WG will make recommendations
+  around support to those responsible for relevant code and responsible
+  for the release engineering operations and automation, but does not
+  own code itself.
+* Code, test case, automation implementations:  this is a working
+  group, no code implementation is the responsibility of this Working
+  Group.
+
+### More Details
+For even more details on scope and conflicting tradeoffs and implications of
+different support schemes, please see [WG LTS Proposal Presentation],
+the [WG LTS meeting minutes], and [WG LTS YouTube Channel].
+
+## Stakeholders
+Stakeholders in this workgroup span multiple personas and SIGs.
+
+There are developers of Kubernetes internals.  Arguably all feature
+code delivering SIGs are stakeholders here in as much as proposals
+for changes in support will impact the way the community develops,
+ships and maintains its code.  From the perspective of technical
+component interoparability across version skews, developers in:
+* SIG API Machinery
+* SIG CLI
+* SIG Node
+will be particularly impacted if wider version skew support to be
+attempted.
+
+There is another set of developers of Kubernetes internals who
+are involved in the integration of Kubernetes with a hosting
+platform or infrastructure providers and delivering Kubernetes
+components to run on cluster nodes. This brings in additional dimensions
+of version skew and does so with more external components and support
+matrix complexity.  These are developers in, for example:
+* SIG Storage (CSI)
+* SIG Network (CNI)
+* SIG Node (CRI)
+* SIG Cloud Provider
+  * SIG AWS
+  * SIG Azure
+  * SIG GCP
+  * SIG IBMCloud
+  * SIG OpenStack
+  * SIG VMware
+* SIG Cluster Lifecycle
+
+There is yet another set of developers of Kubernetes internals who are
+those involved in meta-topics:
+* SIG Release: production of supported release artifacts
+* SIG Testing: how we can most effectively test Kubernetes
+* Product Security Team (PST): security vulnerability handling
+* SIG Architecture: maintains and evolves the design principles of Kubernetes, and provides a consistent body of expertise necessary to ensure architectural consistency over time.  Also defines conformance testing.
+* Steering Committee: scope includes deciding how and when official releases of Kubernetes artifacts are made and what they include
+
+Then of course there is also a variety of types of users of Kubernetes:
+* Kubernetes end users
+* Kubernetes cluster operators
+* Kubernetes vendors, distributions, and hosting providers
+These have their own operational complexities and desires around support
+duration and supported upgrade version skews.
+
+## Deliverables
+The specific deliverable is somewhat To-Be-Determined based on
+initial survey and analysis by the WG.
+
+The initial goal is to enumerate the many and often conflicting
+desires around support, version skew, and upgrade path, with an eye
+for possible areas for improvement.  Today these topics are covered
+in a disjoint set of documents across multiple repositories and the
+official Kubernetes website, so even this enumeration is complicated.
+
+On the one hand the WG's surveys might lead to something larger and
+strategic like a community agreed and implementable KEP returned
+to SIG Release to operationalize.  This will come from discussion
+and analysis of the release frequency and support duration relative
+to adoption and adoption blocking issues.
+
+On the other hand it might lead to more tactical project improvements
+that result in a culture of and releases characterized by higher
+quality and stability, such as:
+* Backported patches more rigorously enforced to only contain critical fixes
+* Critical APIs are stable (vN, not vNbetaX)
+* kubernetes/kubernetes repo master branch kept in a releasable state
+* More clear testing signal
+* Higher test coverage
+* Meaningful version-skew, upgrade, and downgrade tests that are immediately fixed, or patches reverted, when broken
+* Reliable API schema upgrades and downgrades
+* Greater supported version skew for kubectl and client-go
+
+## Timeline and Disbanding
+Working Groups are intended to be time limited endeavors.  We expect
+to survey the state of support in late 2018, especially using KubeCon
+China and KubeCon North America in November and December 2018
+respectively as discussion forums.  In early 2019 we hope this
+coalesces toward concrete proposals, with implementation coming by
+later 2019.
+
+We will evaluate our mid-year progress and next steps at KubeCon
+EU 2019 and look to establish a wrap up plan at that point.
+
+[wg-governance]: https://git.k8s.io/community/committee-steering/governance/wg-governance.md
+[Kubernetes Charter README]: https://git.k8s.io/community/committee-steering/governance/README.md
+[sig-governance]: https://git.k8s.io/community/committee-steering/governance/sig-governance.md
+[WG LTS Proposal Presentation]: https://docs.google.com/presentation/d/1-Z-mUNIs3mUi7AdP1KwoAVNviwKrCoo3lxMb5wzCWbk/edit?usp=sharing
+[WG LTS meeting minutes]: https://docs.google.com/document/d/1J2CJ-q9WlvCnIVkoEo9tAo19h08kOgUJAS3HxaSMsLA/edit?ts=5bda357d
+[WG LTS YouTube Channel]: https://www.youtube.com/playlist?list=PL69nYSiGNLP13_zDqYfUjfLZ2Lu9a3pv-