diff --git a/docs/community/20241112-node-bootstrapping.md b/docs/community/20241112-node-bootstrapping.md
new file mode 100644
index 000000000000..1be7cdd1044e
--- /dev/null
+++ b/docs/community/20241112-node-bootstrapping.md
@@ -0,0 +1,90 @@
+---
+title: ClusterAPI Node Bootstrapping Working Group
+authors:
+    - "@t-lo"
+reviewers:
+    - "@elmiko"
+    - "@eljohnson92"
+    - "@johananl"
+    - "@tormath1"
+
+creation-date: 2024-11-12
+last-updated: 2024-11-12
+status: proposed
+see-also:
+  - https://github.com/kubernetes-sigs/cluster-api/issues/5294
+  - https://docs.google.com/document/d/1Fz5vWwhWA-d25_QDqep0LWF6ae0DnTqd5-8k8N0vDDM/edit
+  - https://github.com/kubernetes-sigs/cluster-api/issues/9157
+  - https://youtu.be/0AhA4Box3MM?si=IfKJfMWmlA9EW7ri&t=172
+---
+
+# Node Bootstrapping Working Group ("CAPI-NoBo")
+
+This document briefly outlines the scope, communication media, and
+stakeholders for a Working Group dedicated to the Provisioning aspect of
+Node Bootstrapping.
+
+Provisioning, in this context, refers to configuring and customising the
+node operating system to prepare it to serve as a ClusterAPI worker cluster node.
+
+
+## User Story and Problem Statement
+
+As a Linux Distribution maintainer aiming to support ClusterAPI, or to improve
+support of ClusterAPI in my distribution, I would like to improve ClusterAPI's
+node bootstrapping process and provide specifications on ClusterAPI's expectations
+and requirements for provisioning-time configuration and customisation.
+
+Initial focus of the working group is on separating node bootstrapping and node
+OS configuration / customisation ("node provisioning" from here on).
+At the time of writing, bootstrapping and provisioning are architecturally
+intertwined; both are implemented in the bootstrap provider.
+This increases maintenance effort and effectively prevents re-using provisioning
+features across bootstrap providers.
+
+For example: the kubeadm bootstrap provider implements two provisioning systems:
+cloud-init and ignition.
+Since there is no architectural separation between bootstrapper and provisioning,
+both implementations cover all concerns, leading to duplicate code and
+to maintenance overhead.
+Also, other providers like e.g. MicroK8s must implement their own OS configuration
+generators since kubeadm's node provisioning implementations cannot be re-used.
+MicroK8s currently only supports cloud-init.
+
+Outside of ClusterAPI, both [cloud-init](https://github.com/canonical/cloud-init)
+and [ignition](https://github.com/coreos/ignition) provisioning is widely adopted
+across distributions.
+While cloud-init is used by general-purpose Linux distributions like Ubuntu/Debian,
+SUSE Linux, Alma, Rocky, Fedora, and Red Hat Enterprise Linux, ignition is popular
+with special-purpose distributions like Fedora CoreOS / Red Hat CoreOS, SuSE MicroOS
+/ SLE Micro / Kalpa, and Flatcar Container Linux.
+It is likely that more provisioning systems exist; a clean separation and guidelines
+will make it easier to add support to ClusterAPI as well as to share implementations acrosss
+bootstrap providers.
+
+## Scope
+
+1. Deliver a clean architectural separation between provisioning and node bootstrapping.
+2. Deliver an example implementation in the kubeadm bootstrapper.
+3. Approach other bootstrappers and provide help and guidance for separating provisioning
+   and re-using provisioning implementations.
+
+## Communication
+
+We will join the [regular ClusterAPI meetings](https://github.com/flatcar-hub/cluster-api?tab=readme-ov-file#-community-discussion-contribution-and-support)
+and share updates on our work in the "Feature Groups" section, which is a regular part of
+the ClusterAPI meetings)
+
+Chat with stakeholders on Kubernetes [Slack](http://slack.k8s.io/) in the
+[cluster-api](https://kubernetes.slack.com/archives/C8TSNPY4T) channel.
+
+## Stakeholders
+
+Primary Stakeholders are listed below:
+
+- The Flatcar Container Linux project
+  - Johanan Liebermann (@johananl, Microsoft)
+  - Mathieu Tortuyaux (@tormath1, Microsoft)
+  - Thilo Fromm (@t-lo, Microsoft)
+- Michael McCune (@elmiko, Red Hat)
+- Evan Johnson, (@eljohnson92, Akamai)