Rust Compiler Team: Organization, Communication, and Meetings

# About the compiler team rustc is maintained by the [Rust compiler team][team]. The people who belong to this team collectively work to track regressions and implement new features. Members of the Rust compiler team are people who have made significant contributions to rustc and its design. ## Discussion Currently the compiler team chats in Zulip: - Team chat occurs in the [`t-compiler`][zulip-t-compiler] stream on the Zulip instance - There are also a number of other associated Zulip streams, such as [`t-compiler/help`][zulip-help], where people can ask for help with rustc development, or [`t-compiler/meetings`][zulip-meetings], where the team holds their weekly triage and steering meetings. ## Reviewers If you're interested in figuring out who can answer questions about a particular part of the compiler, or you'd just like to know who works on what, check out [triagebot.toml's assign section][map]. It contains a listing of the various parts of the compiler and a list of people who are reviewers of each part. ## Rust compiler meeting The compiler team has a weekly meeting where we do triage and try to generally stay on top of new bugs, regressions, and discuss important things in general. They are held on [Zulip][zulip-meetings]. It works roughly as follows: - **Announcements, MCPs/FCPs, and WG-check-ins:** We share some announcements with the rest of the team about important things we want everyone to be aware of. We also share the status of MCPs and FCPs and we use the opportunity to have a couple of WGs giving us an update about their work. - **Check for beta and stable nominations:** These are nominations of things to backport to beta and stable respectively. We then look for new cases where the compiler broke previously working code in the wild. Regressions are important issues to fix, so it's likely that they are tagged as P-critical or P-high; the major exception would be bug fixes (though even there we often [aim to give warnings first][procedure]). - **Review P-critical and P-high bugs:** P-critical and P-high bugs are those that are sufficiently important for us to actively track progress. P-critical and P-high bugs should ideally always have an assignee. - **Check S-waiting-on-team and I-nominated issues:** These are issues where feedback from the team is desired. - **Look over the performance triage report:** We check for PRs that made the performance worse and try to decide if it's worth reverting the performance regression or if the regression can be addressed in a future PR. The meeting currently takes place on Thursdays at 10am Boston time (UTC-4 typically, but daylight savings time sometimes makes things complicated). ## Team membership Membership in the Rust team is typically offered when someone has been making significant contributions to the compiler for some time. Membership is both a recognition but also an obligation:

This section describes the Rust compiler team, including how they communicate via Zulip, how to find reviewers for specific parts of the compiler, and the structure of their weekly meetings. The meetings cover announcements, bug triage, performance reviews, and issue discussion. Membership in the team is offered to those who have made significant contributions.