Operations

“Operations” is a part of the Compiler Team that takes care of organizational and maintenance work and in general help things moving forward. T-compiler ops lives on Zulip under #t-compiler/ops.

Here is a list of recurring tasks. Ideally run through this list every week. If there are blockers or doubts, after having acquired the right context, don’t hesitate to ping people around. Contributors are the best resource of the project (and we want to be mindful of their time) and are always helpful.

You can trigger a discussion about a specific topic, issue or pull request by opening a new topic on Zulip in #t-compiler or, if it needs consensus and more focus from the team, it can can be labeled I-compiler-nominated and will be discussed in a meeting (see section Meetings).

Issues hygiene

• Issue to be prioritized: see prioritization.
• P-high issues without assignee: ideally this category of issues should have an assignee (filter out those without a PR). In rare cases it’s fine if they don’t.
• MCP in FCP status, close seconded since more 10 days, ensure no open concerns
• Check open MCPs: MCP is a protocol to bring proposals to the compiler team attention. Ensure MCPs are moving towards one of these two outcome, being seconded or being closed for lack of seconding. When it’s clear that an MCP won’t be seconded or is abandoned, after about two or three months is ok to query its status and evaluate closing it. Otherwise try to get them unstuck.
• Issues needing a MCVE
• Issues and PRs that are going through FCP: check if the team need to check their box. These issues are in the weekly triage meeting agenda.

Prioritization for T-compiler

See here how to prioritization works.

Some useful filters when looking at regressions.

• Nightly regressions without priority
• Beta regressions without priority
• Stable regressions without priority
• Untriaged regressions without a priority

PRs hygiene

• Every PR should have a team assigned
  • PR without a team label
  • Waiting on author
  • Waiting on a review

Things to do a week before the release:

• No regression without priority: ensure they’ve been fixed and if not try to get the team attention.
• No beta regressions or stable regressions regressions without an owner, filter out those out without a PR.
• No beta regressions or stable regressions regressions work in progress, ideally they should all be merged.
• Ensure breaking changes (i.e. regressions agreed to be acceptable) have a corresponding issue tagged relnotes-tracking-issue, see list of release notes. T-release will then pick them up and add them to the release notes.

After the release

• Check carefully which regressions can be closed as “accepted”. Add a comment clarifying that the PR causing the regression is accepted as breaking change, example: “Closing since PR #123456 will be mentioned in the release notes”. Discussions and comments about this practice can be directed on Zulip.

Meetings

T-compiler has two kinds of meetings: triage and design meetings. Triage meetings happen weekly on Thursdays (you can subscribe to the Team Compiler calendar from this repository ), there is a tool to generate 80% of the meeting’s agenda (see Triage meetings for details). Design meetings proposals are advanced on the T-compiler repository and scheduled during recurrent steering meetings (where the next design meetings are scheduled). Design meetings also need an agenda and a bit of work to summarize the topic and bring together documentation, invite relevant people and so on.

Triage meetings

First, ensure that relevant issues are labelled as T-compiler:

• Issues labeled with I-prioritize
• Pull requests nominated for the stable release channel backport
• Pull requests nominated for the beta release channel backport
• Issues labeled I-compiler-nominated (i.e. needing a T-compiler discussion)
• Pull requests waiting on a team’s feedback
• Issues classified with priority P-high
• Issues classified with priority P-critical

..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 sends a notification to the #t-compiler/prioritization/alerts Zulip channel.

Ideally, all T-compiler issues with a I-prioritize label 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 to other contributors.

Review stable, beta and nightly and try to ensure they are assigned when possible.

The final step prior to generating the agenda is to accept Major Change Proposals (MCP), this is usually automated. MCPs that have been in the Final Comment Period (FCP) phase (identified by having the final-comment-period label) for more than ten days can be accepted. If an MCP has no unresolved concerns (look for the has-concerns label), you can remove the final-comment-period label, add the major-change-accepted label and close the issue.

Finally, the meeting agenda can be generated. Clone and build triagebot and run:

$ cargo run --bin prioritization-agenda

Copy the content into a new HackMD in the “Rust Lang Compiler Team” space. The tool will also download the latest weekly compiler triage logs. In case it didn’t work out, manually copy the most recent performance triage logs (doing a bit of cleanup, removing anything that won’t display well in Zulip)

Add additional manual details to the agenda:

• Add summaries of stable/beta nominations (e.g. who nominated the backport and why)
• Add summaries of PRs waiting on the team (i.e. why are they waiting)
• Add initial impressions of P-critical/P-high bugs
• Add summaries of nominated issues (e.g. who the assignee is, why it was nominated, etc)
• Populate the oldest PRs waiting on review
  • Use judgement to determine whether a ping is appropriate (e.g. if the pull request is an experiment, it may not need a review; how long has it been since review activity; what do recent comments say?)

About two hours prior to the meeting, announce and share the completed agenda in the Zulip thread for the upcoming meeting (creating it if it does not already exist):

Hello @*T-compiler/meeting*, triage meeting in about 2h.
Pre-triage done in #**t-compiler/prioritization/alerts**.
Meeting agenda [on HackMD](https://hackmd.io/aaabbbccc123456)

It is always recommended to re-run the generator and copy any new details over to the agenda as issue statuses on GitHub may have changed.

After the meeting, there are a few closing tasks:

• Lock the agenda on HackMD assigning write permissions to Owners.
• Remove the to-announce label from MCPs, unless this label was added exactly during the meeting (and therefore will be seen during the following meeting).
• Remove to-announce FCPs from rust-lang/rust, compiler-team and the forge. Same disclaimer as before regarding changes during the meeting.
• Accept or decline beta nominated and stable nominated backports that have been accepted during the meeting. For more info check t-release backporting docs
  • To accept a backport, add a {beta,stable}-accepted label and keep the {beta,stable}-nominated label. Other automated procedures will process these pull requests, it’s important to leave both labels. Add a comment on Github linking the Zulip discussion.
  • To decline a backport, simply remove {beta,stable}-nominated label. Add a comment on Github explaining why the backport was declined and link the Zulip discussion.
• Remove I-compiler-nominated label from issues that were discussed. Sometimes not all nominated issues are discussed (because of time constraints) and can slip to the next meeting.

Rest of the world

These filters are for checking what’s happening in other teams

• List of open RFCs (all teams) waiting for the team to discuss or check the proposal, can anything be done to help moving them forward?

Useful tips

Github Issues Dashboard

You can utilize the GitHub Issues Dashboard to create custom filters. The filters allow you to aggregate both issues and PRs from multiple repositories, and allows applying advanced filters. See https://github.blog/changelog/2025-04-02-github-issues-dashboard-updates/.

Example custom filters

Mostly intended for rust-lang/rust