Remove last mentions of WG-prioritiation and ICE-breakers ping groups

src/compiler/prioritization.md

@@ -49,9 +49,7 @@ Examples of things we typically judge to be “critical” bugs:
   - If a regression has been in stable for a release or two (either because we are still awaiting a
     fix, or because the bug had laid dormant i.e. undetected), we typically lower the priority as
     well, because by that time, if the users have not raised a ruckus about the regression, that
-    is a sign that it is inherently not a critical issue.
-    - e.g. [an issue that would have been `P-critical` but ended up being
-      `P-high`][critical_downgrade_example]
+    is a sign that it is inherently not a critical issue
 - Regressions where code still compiles but does something different than it used to do (dynamic
   semantics have changed)
   - Mitigating conditions that may lower priority:
@@ -76,8 +74,6 @@ Examples of things we typically judge to be “critical” bugs:
 A `P-critical` issue will receive the most attention. It must be assigned one or several people as
 soon as possible, and the rest of the team should do their best to help them out if/when applicable.
 
-[critical_downgrade_example]: https://rust-lang.zulipchat.com/#narrow/stream/227806-t-compiler.2Fwg-prioritization/topic/pre-meeting.20triage.202020-04-09.20.2354818
-
 ## P-high
 `P-high` issues are issues that need attention from the compiler team, but not to the point that
 they need to be discussed at every meeting. They can be `P-critical` issues that have a mitigating
@@ -122,14 +118,13 @@ First, ensure that relevant issues are labelled as `T-compiler`..
 - [Issues classified with priority `P-high`](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AP-high+-label%3AT-compiler+-label%3AT-cargo+-label%3AT-core+-label%3AT-doc+-label%3AT-infra+-label%3AT-lang+-label%3AT-libs+-label%3AT-libs-api+-label%3AT-release+-label%3AT-rustdoc+-label%3AA-rustdoc+-label%3AA-rustdoc-ui)
 
 ..and that prioritization has been completed. Regressions labeled with `I-prioritize` are signaling
-that a priority assessment is waiting. When this label is added to an issue, the `triagebot` creates
-automatically a notification for @*WG-prioritization* members on [the
-`#t-compiler/prioritization/alerts` Zulip channel][prio_channel].
+that a priority assessment is waiting. When this label is added to an issue, the `triagebot` sends a
+notification to the [`#t-compiler/prioritization/alerts`][prio_channel] Zulip channel.
 
-[prio_channel]: https://rust-lang.zulipchat.com/#narrow/stream/245100-t-compiler.2Fwg-prioritization.2Falerts
+[prio_channel]: https://rust-lang.zulipchat.com/#narrow/channel/245100-t-compiler.2Fprioritization.2Falerts
 
 To assign a priority, replace the `I-prioritize` label with one of `P-critical`, `P-high`,
-`P-medium` or `P-low` and adding a succinct comment to link the Zulip discussion where the issue
+`P-medium` or `P-low` and add a succinct comment to link the Zulip discussion where the issue
 prioritization occurred, example of a template for the comment:
 
 > Assigning priority (discussion on [Zulip](#)).
@@ -138,12 +133,11 @@ prioritization occurred, example of a template for the comment:
 
 Tip: use [Github Saved Replies](https://docs.github.com/get-started/writing-on-github/working-with-saved-replies) to create a template comment.
 
-Ideally, all [`T-compiler` issues with a `I-prioritize` label][issues_needing_prio] to have a
+Ideally, all [`T-compiler` issues with a `I-prioritize` label][issues_needing_prio] should have a
 priority assigned, or strive to reach this goal: sometimes different factors are blocking issues
-from being assigned a priority label, either because the report or the context is unclear or
-because cannot be reproduced and an MCVE would help. Don't hesitate to ask for clarifications to
-the issue reporter or ping the `ICEbreaker` team when an ICE ("Internal Compiler Errors") needs a
-reduction (add a comment on the issue with `@rustbot ping icebreakers-cleanup-crew`)
+from being assigned a priority label, either because the report or the context is unclear or because
+cannot be reproduced and an MCVE would help. Don't hesitate to ask for clarifications to the issue
+reporter or to other contributors.
 
 Review [stable][stable_regressions], [beta][beta_regressions] and [nightly][nightly_regressions] and
 try to ensure they are assigned when possikle.
@@ -159,19 +153,16 @@ close the issue.
 
 [mcp_fcp]: https://github.com/rust-lang/compiler-team/issues?q=is%3Aissue+is%3Aopen+label%3Amajor-change+label%3Afinal-comment-period
 
-Finally, the meeting agenda can be generated. Clone and build [`triagebot`][triagebot] and set the
-`GITHUB_TOKEN` environment variable with a GitHub API token.
+Finally, the meeting agenda can be generated. Clone and build [`triagebot`][triagebot] and run:
 
 [triagebot]: https://github.com/rust-lang/triagebot
 
-Then generate the agenda with:
-
 ```
 $ cargo run --bin prioritization-agenda
 ```
 
 Copy the content into a new HackMD in the "Rust Lang Compiler Team" space. Copy the most recent
-[performance triage logs][perf_triage_log] and remove anything that won't display well in Zulip
+[performance triage logs][perf_triage_log] (doing a bit of cleanup, removing anything that won't display well in Zulip)
 
 [perf_triage_log]: https://github.com/rust-lang/rustc-perf/tree/master/triage#triage-logs
 

src/release/issue-triaging.md

@@ -113,14 +113,14 @@ There are many different labels that can be applied to issues.
     - `regression-from-stable-to-{beta,nightly}`: Something that regressed from the a stable release to beta or nightly channel.
 - [`I-*`]: Different labels about the nature[^2] of an issue.
     - `I-ICE`: Internal compiler error.
-    - `I-prioritize`: Indicates that the issue should be additionally triaged by the [T-compiler prioritization working group (WG-priority)](../compiler/prioritization.md) to assign a priority `P-*` if applicable to indicate the urgency.
+    - `I-prioritize`: Indicates that the issue should be additionally triaged by [T-compiler/ops](../compiler/prioritization.md) to assign a priority `P-*` if applicable to indicate the urgency.
     - `I-heavy`: Heavy code (binary size).
     - `I-slow`: Slow run-time performance.
     - `I-hang`: The compilation fails to complete after a long time.
     - `I-crash`: The compiler or generated code crashes but does not manifest as an ICE, e.g. SIGSEGV or access violations.
     - `I-unsound`: Library, compiler, type system or language unsoundness.
     - `I-compilemem`: Excessive memory usage during compilation.
-    - `I-compiletime`: Slow compilation time. 
+    - `I-compiletime`: Slow compilation time.
     - `I-{team}-nominated`: Issue is nominated for discussion by `{team}`. E.g. `I-compiler-nominated`.
     - `I-lang-easy-decision`: The decision needed by T-lang is conjectured (by the person applying the label) to be easy or perfunctory. Note that this label does not imply `I-lang-nominated`; the nomination label should be applied simultaneously if the person apply the label wants to nominate the issue for T-lang discussion.
 - [`P-*`]: Priority labels. Applied using the [compiler prioritization procedure](../compiler/prioritization.md).

src/triagebot/labeling.md

@@ -56,7 +56,7 @@ Formally the grammar is:
 
 ### Permissions
 
-All labels can be assigned by rust-lang organization team members (and wg-triage, wg-prioritization, and wg-async).
+All labels can be assigned by rust-lang organization team members (and wg-triage, wg-async).
 Users not on a team can only assign labels that are explicitly authorized in `triagebot.toml`.
 It is encouraged for maintainers to allow the majority of labels to be applied by anyone.
 An example of one that would be restricted is `beta-accepted`, since accepting a backport to beta is usually only done by a team member.

src/triagebot/pinging.md

@@ -9,7 +9,7 @@ The message will include a `cc` line that `@`-mentions all members of the team.
 
 ## Usage
 
-On repositories with a ping group configured, any Rust team member (and wg-triage, wg-prioritization, and wg-async) can write a GitHub comment such as:
+On repositories with a ping group configured, any Rust team member (and wg-triage, wg-async) can write a GitHub comment such as:
 
 ```text
 @rustbot ping windows
@@ -21,7 +21,7 @@ which would cause triagebot to post a comment notifying the members of the `wind
 
 To be pinged, teams have to be created in the [Rust team repository](https://github.com/rust-lang/team).
 Frequently those teams will be marked as `marker-team`, meaning that they do not appear on the website.
-The [Icebreakers LLVM team](https://github.com/rust-lang/team/blob/master/teams/icebreakers-llvm.toml#L2) is an example.
+The [WASM team](https://github.com/rust-lang/team/blob/master/teams/wasm.toml#L2) is an example.
 
 Additionally, the team needs to be configured in the repository's `triagebot.toml` file.
 

src/triagebot/transfer.md

@@ -21,7 +21,7 @@ implements diagnostic reports.
 
 **WARNING:** Transferring is a partially destructive command. For example, labels and milestones that don't exist in the target repository will be removed from the issue.
 
-The transfer command is limited to team members of the rust-lang org, as well as members of `wg-triage`, `wg-prioritization`, and `wg-async`, and transfers can only happen to repositories in the rust-lang org. Also, the destination repository must have triagebot enabled on it.
+The transfer command is limited to team members of the rust-lang org, as well as members of `wg-triage` and `wg-async`. Transfers can only happen to repositories in the rust-lang org. Also, the destination repository must have triagebot enabled on it.
 
 ## Configuration