Replace mentions of libs-api

src/development/feature-lifecycle.md

@@ -21,7 +21,7 @@ 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.
 
-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.
+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&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.
 
 Note that an ACP is not strictly required: you can just go ahead and submit a pull request with an implementation of your proposed API, with the risk of wasted effort if the library team ends up rejecting this feature. However do note that this risk is always present even if an ACP is accepted, as the library team can end up rejecting a feature in the later parts of the stabilization process.
 

src/development/stabilization.md

@@ -29,7 +29,7 @@ You can see an example of a stabilization report in [#88581](https://github.com/
 
 ## Before writing a PR to stabilize a feature
 
-Check to see if a FCP has completed first. If not, either ping `@rust-lang/libs-api` if you're a member of the `rust-lang` organization,
+Check to see if a FCP has completed first. If not, either ping `@rust-lang/libs` if you're a member of the `rust-lang` organization,
 or leave a comment asking about the status of the feature.
 
 This will save you from opening a stabilization PR and having it need regular rebasing while the FCP process runs its course.
@@ -107,12 +107,12 @@ To stabilize a feature, follow these steps:
 
 0. Create a stabilization report in the tracking issue for the feature being stabilized.
 0. (Optional) For partial stabilizations, create a new partial stabilization PR for the subset of the issue being stabilized.
-0. Ask a **@rust-lang/libs-api** member to start an FCP on the tracking issue and wait for the FCP to complete (with `disposition-merge`).
+0. Ask a **@rust-lang/libs** member to start an FCP on the tracking issue and wait for the FCP to complete (with `disposition-merge`).
 0. Change `#[unstable(...)]` to `#[stable(since = "CURRENT_RUSTC_VERSION")]`. `CURRENT_RUSTC_VERSION` here is meant in a literal sense and not to be replaced with the spelled out version number.
 0. Remove `#![feature(...)]` from any test or doc-test for this API. If the feature is used in the compiler or tools, remove it from there as well.
 0. If applicable, change `#[rustc_const_unstable(...)]` to `#[rustc_const_stable(since = "CURRENT_RUSTC_VERSION")]`.
 0. Open a PR against `rust-lang/rust`.
-   - Add the appropriate labels: `@rustbot modify labels: +T-libs-api`.
+   - Add the appropriate labels: `@rustbot modify labels: +T-libs`.
    - Link to the tracking issue by adding "Closes #XXXXX".
 
 You can see an example of stabilizing a feature with [tracking issue #81656 with FCP](https://github.com/rust-lang/rust/issues/81656) and the associated [implementation PR #84642](https://github.com/rust-lang/rust/pull/84642).

src/team/meetings.md

@@ -12,7 +12,7 @@ Agendas are generated by the [`fully-automatic-rust-libs-team-triage-meeting-age
 which will include all relevant issues and PRs, such as those tagged with `I-nominated` or `S-waiting-on-team`.
 
 If you have any specific topics you'd like to have discussed in a meeting, feel free to open an issue on the [`libs-team`](https://github.com/rust-lang/libs-team/) repository
-and mark it as `I-nominated` and `T-libs` or `T-libs-api`. Or just leave a message in the Zulip channel.
+and mark it as `I-nominated-libs`. Or just leave a message in the Zulip channel.
 
 All the meetings, including those of the library working groups, can be found on our Google Calendar:
 

src/team/reviewing.md

@@ -14,7 +14,7 @@ But please keep in mind:
     - You are confident it will not cause any breakage or regress performance.
     - It does not change the public API, including any stable promises we make in documentation, unless there's a finished FCP for the change.
       - For unstable API changes/additions, it can be acceptable to skip the RFC process if the design is small and the change is uncontroversial.
-        Make sure to involve `@rust-lang/libs-api` on such changes.
+        Make sure to involve `@rust-lang/libs` on such changes.
 - Always be polite when reviewing: you are a representative of the Rust project, so it is expected that you will go above and beyond when it comes to the Code of Conduct.
 
 See <https://forge.rust-lang.org/compiler/reviews.html> for more information on reviewing.