​​Compiler team tasks and roles
​​The goal of this document is to compile a list of things the compiler team (or some other team in the Rust project) needs to do. I hope to try and make the list fairly granular. The idea is to first figure out what are all the bits of work / communication / etc that have to be happening, and then to be able to think about how and where they should be taking place.

​​Team direction

  • ​​Deciding what projects we should be working on
  • ​​Tracking what larger projects we are actively working on and their status
  • ​​Recording summaries from various meetings
  • ​​Re-evaluating our overall priorities every so often (this is what I intended the steering meeting for, but we've also come to use it for other things, which seems fine)

​​Status updates and intercommunication

  • ​​Allow outsiders to track what compiler team is up to, keep up excitement
  • ​​Keep team abreast of the overall plans within a WG
  • ​​particularly those that may affect other groups
  • ​​Allow people to raise questions (e.g., how to design this thing that affects HIR?)
  • ​​Discuss and/or respond to issues tagged with I-nominated or S-waiting-for-team
  • ​​Where do we go with design discussions and tricky questions? 
  • ​​Sometimes these are specific questions: settling the question of 'gcx​
  • ​​Other times, more open-ended:
  • ​​desugaring some parts of async-await seem harder, can we adjust the design of HIR?
  • ​​similarly, MIR optimizations are hard, can we change the design of MIR?

​​Documentation

  • ​​Expanding rustc-guide to get full coverage
  • ​​Updating rustc-guide as the code changes
  • ​​API doc coverage 

​​Triage and tracking correctness bugs

  • ​​Triaging new bugs as they are filed to figure out if they are regressions, what part of the compiler they pertain to, etc.
  • ​​Tracking regressions and making sure they get fixed.
  • ​​Triaging P-medium and P-low bugs
  • ​​Prioritizing bugs with no P- label
  • ​​Tracking future-incompatibility analyses and diagnostics
  • ​​Identify issues (+ PR’s?) that should have T-compiler label, but do not (and tag them accordingly)

​​Tracking compilation time (how long does compiler take)

  • ​​Measure compiler performance, identify regressions
  • ​​Measure memory usage, identify regressions
  • ​​Curate benchmarks, decide on appropriate benchmark suite
  • ​​in particular, being able to explain why a particular benchmark is included
  • ​​Identify, within each compiler performance benchmark and each scenario, what is taking up compilation time

​​Tracking performance of generated code

  • ​​Measure execution time of generated code, identify regressions
  • ​​Curate benchmarks, decide on appropriate benchmark suite

​​Contributors

  • ​​Finding people to fix regressions or bugs 
  • ​​Soliciting volunteers
  • ​​Providing a mentoring pathway to help committed folks learn more 
  • ​​Ensuring prompt reviews (for the person opening the PR)
  • ​​Ensuring review load is manageable (for the people reviewing PRs)
  • ​​Celebrating contributors 

​​Within a working group

  • ​​Recording summaries from various meetings
  • ​​Running meetings: setting up agenda and monitoring meeting’s progress through it
  • ​​Breaking up a complex goal into smaller pieces, as part of a working group