diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index ea8164f..5b0860d 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -17,7 +17,7 @@
 ---
 
 - [The feature lifecycle](./feature-lifecycle/summary.md)
-    - [Landing new features](./feature-lifecycle/new-unstable-features.md)
+    - [API Change Proposals](./feature-lifecycle/api-change-proposals.md)
     - [Using tracking issues](./feature-lifecycle/tracking-issues.md)
     - [Stabilizing features](./feature-lifecycle/stabilization.md)
     - [Deprecating features](./feature-lifecycle/deprecation.md)
diff --git a/src/feature-lifecycle/api-change-proposals.md b/src/feature-lifecycle/api-change-proposals.md
new file mode 100644
index 0000000..878cad4
--- /dev/null
+++ b/src/feature-lifecycle/api-change-proposals.md
@@ -0,0 +1,21 @@
+# API Change Proposals (ACP)
+
+Changes to the standard library's unstable API go through the libs ACP process.
+
+The API Change Proposal process is intended to be a lightweight first step to
+getting new APIs added to the standard library. The goal of this process is to
+make sure proposed API changes have the best chance of success. The ACP process
+accomplishes this by ensuring all changes have had a libs-api team member
+second the proposal indicating that they are optimistic that the proposal will
+pass its eventual FCP and by focusing the initial discussion on the problems
+being solved and concrete motivating examples.
+
+You can create an ACP in the `rust-lang/libs-team` repo using [this issue template](https://github.com/rust-lang/libs-team/issues/new?assignees=&labels=api-change-proposal%2C+T-libs-api&template=api-change-proposal.md&title=%28My+API+Change+Proposal%29).
+
+Once a t-libs-api team member has reviewed the ACP and judged that it should
+move forward they will second the ACP (via `@rfcbot second`) and initiate an
+ICP (inital comment period). This initial comment period is intended to give
+other stake holders a chance to participate in the initial discussion prior to
+starting the implementation. Once this ICP has completed you should proceed
+with the implementation of your proposal and then move on to the next step of
+the feature lifecycle, creating a tracking issue.
diff --git a/src/feature-lifecycle/new-unstable-features.md b/src/feature-lifecycle/new-unstable-features.md
deleted file mode 100644
index faa9076..0000000
--- a/src/feature-lifecycle/new-unstable-features.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# Landing new features
-
-**Status:** Stub
-
-New unstable features can be added and approved without going through a Libs FCP. There should be some buy-in from Libs that a feature is desirable and likely to be stabilized at some point before landing though.
-
-If you're not sure, open an issue against `rust-lang/rust` first suggesting the feature before developing it.
-
-All public items in the standard library need a `#[stable]` or `#[unstable]` attribute on them. When a feature is first added, it gets a `#[unstable]` attribute.
-
-Before a new feature is merged, those `#[unstable]` attributes need to be linked to a [tracking issue](./tracking-issues.md).