Rework the feature lifecycle

Author: Amanieu

src/feature-lifecycle/api-change-proposals.md

@@ -1,3 +1,51 @@
 # The feature lifecycle
 
-**Status:** Stub
+## Identifying the problem
+
+The first step before proposing any change to the standard library is to properly identify the problem that is trying to be solved. This helps to identify cases of the [XY problem] where a better solution exists without needing any changes to the standard library.
+
+For this reason it is helpful to focus on real problems that people are encountering, rather than theoretical concerns about API design.
+
+[XY problem]: https://en.wikipedia.org/wiki/XY_problem
+
+## Suitability for the standard library
+
+Unlike third party crates on crates.io, the Rust standard library is not versioned. This means that any stable API that is added can *never* be removed or modified in a backwards-incompatible way. For this reason, the standard library maintainers place a high bar on any change to the standard library API.
+
+APIs that are well suited to the standard library are things that require language and/or compiler support, or that extend existing standard library types. Complex APIs that are expected to evolve over time (e.g. GUI frameworks) are a poor fit due to the lack of versioning.
+
+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 are reviewed by the library team, 
+who will evaluate the proposal and accept it if they are optimistic that the proposal will
+be merged and pass its eventual FCP.
+
+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). This should include a sketch of the proposed API, but does not have to be the final design that will be implemented.
+
+## API design exploration
+
+Once a feature is deemed suitable for inclusion in the standard library, the exact design should be iterated on to find the best way to express it as a Rust API. This iteration should happen in community forums such as [Rust internals](https://internals.rust-lang.org/) where all members of the community can comment and propose improvements.
+
+Keep the following points in mind during the discussion:
+- Resist the temptation to make the API overly general since this tends to increase complexity and lowers the chance of it being accepted by the library team. Instead, try to stay focused on the problem that needs solving.
+- An alternative that should *always* be considered is simply adding this feature via a third party crate. This even possible when adding new methods to standard library types by using extension traits.
+- In the case of "convenience" functions which are simply shorthands for something that is already possible with existing APIs, the cost of extending the standard library surface should be weighed against the ergonomic impact of the new functions.
+
+The library team itself is not directly involved in this discussion, but individual members may comment to provide feedback.
+
+## Implementation
+
+Once the API design space has been explored, an implementation based on the favored solution should be proposed as a pull request to the `rust-lang/rust` repository.
+
+The pull request should include a summary of the alternatives that were considered. This is helpful for reviewers since it avoids duplicating this exploration work as part of the review. A PR submitted without this may be closed with a request to explore more alternatives.
+
+If an ACP has not been filed for the proposed feature, the PR will need to be reviewed by the library team to determine its suitability for the standard library.
+
+## Tracking and stabilization
+
+Before a PR is merged, you will be asked to open a [tracking issue](tracking-issues.md) which will track the progress of the feature until its [stabilization](stabilization.md).
+
+There are two exceptions to this:
+- Modifications of an existing unstable API can re-use the existing tracking issue for this API.
+- Changes that are instantly stable (e.g. trait implementations on stable types) do not need a tracking issue.