owned this note
owned this note
Published
Linked with GitHub
---
tags: rustc, areas
---
# Proposal in a nutshell
* Add a notion of "areas", each of which define some portion of the rustc codebase.
* Each area has a github team and Zulip stream, as well as membership.
* These replace existing working groups that don't have specific goals as well as the "expert map".
## Use cases
## Leading an area
Leading an area should not be a large commitment. It mostly means that you are aware of what's going on and can help figure out the right person to answer a question. At minimum, it means you should be generally monitoring the corresponding Zulip stream(s).
However, areas can also be more active. For example, areas can coordinate projects (which may eventually be spun out into dedicated project groups, if they're big enough) or have a wishlist of ideas.
## Area check-ins
XXX?
## Starting list
Rather than try to make a huge jump, we propose to start by defining an initial list of areas. Once we know how the setup should be, we can add more (see below for a possible list). These mostly correspond to existing working groups and areas that we've already created Zulip streams for and the like.
| group | lead(s) | areas | subsumes |
| --- | --- | --- | --- |
| diagnostics | estebank | diagnostic formatting code | wg-diagnostics |
| mir | oli-obk | building MIR, optimizations, generator transform | wg-mir-opt |
| codegen | eddyb | partitioning, debuginfo, type layout | (this is new) |
| llvm | nagisa | LLVM-specific problems, ThinLTO, PGO | wg-llvm |
| constant_evaluation | oli-obk | const_eval, miri | t-compiler/const-eval |
## Full list of areas
This is a potential "full list" of areas. The goal is to keep them broad because a fine-grained list quickly becomes overwhelming. For each area, we also call out a few notable bits of code that have particular owners and maintainers.
| group | lead(s) | areas |
| --- | --- | --- |
| plumbing | | query system, metadata, incremental compilation, self profile |
| diagnostics | | diagnostic formatting code |
| frontend | | lexer, parser, grammar, name resolution, macro expansion, ast |
| hir | | HIR definition and lowering |
| mir | | building MIR, optimizations, generator transform |
| type_check | | type collection/checker, exhaustiveness checking, misc things like unsafety checking and liveness |
| traits | | trait selection, projection, fulfillment |
| borrow_check | | borrow check, region checker, drop elaboration, polonius? |
| codegen | | partitioning, debuginfo, type layout |
| llvm | | LLVM-specific problems, ThinLTO, PGO |
| constant_evaluation | | const_eval, miri |
| rust_analyzer | | |
| rustc_dev_guide | | |
Up and coming:
* polonius
* chalk
## Minutes from meeting
* Explored the concept and talked over
* Question: what does membership mean?
* Should we even have members?
* Do we expect to be making FCP-style decisions for these teams, where membership is highly relevant?
* Question: who decides to add new members?
* and does that imply write access to things?
* Things we might want to do with these subteams
* Ping groups looking for people that might want to check them out.
* either on Zulip or Github
* Find the right people to fix P-critical issues.
* Find appropriate reviewers for a PR (e.g. [#266](https://github.com/rust-lang/highfive/pull/266
* Alternative we started iterating on towards the end was indexing on **activity and engagement level**
* [Core comment](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.20areas.20of.20the.20compiler.20compiler-team.23288/near/202099981)
* Notification groups -- dormant, no active leadership, anyone can add themselves
* Project groups -- active leads, defined goals, but in some sense temporary
* members get privileges to repos, or r+ rights within a particular area, etc
* check-ins at compiler team meeting
* maybe regular meetings, maybe not
* Team and subteam -- fixture and permanent commitment
* broad decision making powers independent from other teams (even parent team)
* regularly scheduled meetings
* part of the roadmap
* Projects and efforts can move up and down:
* maybe LLVM is dormant now, but someone is very excited
* or maybe there aren't as many active people right now in some area, so it becomes notification group
* or a project is over and just ceases to exist too, that's ok