Library API team

Author: Amanieu

src/feature-lifecycle/summary.md

@@ -17,7 +17,7 @@ APIs that are well suited to the standard library are things that require langua
 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, 
+accomplishes this by ensuring all changes are reviewed by the library API team,
 who will evaluate the proposal and accept it if they are optimistic that the proposal will
 be merged and pass its eventual FCP.
 
@@ -28,7 +28,7 @@ You can create an ACP in the `rust-lang/libs-team` repo using [this issue templa
 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.
+- 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 API 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 is 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.
 
@@ -40,7 +40,7 @@ Once the API design space has been explored, an implementation based on the favo
 
 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.
+If an ACP has not been filed for the proposed feature, the PR will need to be reviewed by the library API team to determine its suitability for the standard library.
 
 ## Tracking and stabilization