2018.12.14
The steering meeting was focused on mentoring. Some of the prompting questions:
- How can we help move people from "working group participant" to "full-fledged team member"?
- How can we reduce the "bus factor" for cricial modules like the type checker, type resolver, etc?
A summary of the major points raised follows. If you prefer, you can read the full transcript on Zulip.
Major points: Mentoring
- it seems good to try and list out the parts of the compiler and who
is an expert in each
one,
perhaps in some kind of "introduction to the compiler team" page on the repository
- this can help identify where to direct your questions about code X
- but also where we need to increase the number of knowledgable people
- it would be great if we had an organized off-ramp system
for folks who have been active in a working group and are looking to broaden their knowledge
- maybe we can pair up such folks with someone more experienced
- this is a different sort of mentoring, since active people from a WG are already familiar with how the compiler works, and thus able to work at a higher level
- we need to find a way to make it easier to find "intermediate-level mentoring opportunities".
- we might try to actively increase bus factor via fixing issues, writing tests, or writing docs
- writing tests can be driven via code coverage measurements
- writing docs can be driven via
deny(missing_docs)as well as push to complete the missing rustc-guide sections - one problem with writing documentation is that there always seems to be something that is higher priority, maybe implying we need it as a roadmap item
- a dedicated
#t-compiler/helpstream would be a good way to call attention and request mentoring
Major points: process for refactorings, documentation
Towards the end, we also discussed the procedure we should use for larger compiler refactorings as well as how to ensure the compiler is documented.
- before landing a massive refactoring or new architecture:
- ideally, talk out the design on an internals thread to achieve some light consensus
- expect documentation in the form of rustc-guide chapters
- some examples where we should do this:
- in terms of the rustc-guide:
- it'd be great to improve mdbook to permit for graphs
- maybe we can add graphviz support into mdbook
- we should not neglect doc comments
- and we can link back and forth copiously (and make sure we check for dead links)
- it'd be great to improve mdbook to permit for graphs