2019.01.17
We discussed the upcoming Rust All Hands.
One of the first things we focused on is trying to get consensus about what the P1 Problems are that we are aiming to tackle. Our goal is to have this list complete before the all hands. Our initial list looked like this:
- compilation time
- better compilation time investigation tools/analysis
- this should work in cooperation with cargo, so we can see whole story
- rls, completions
- “too hard to do anything” — technical debt
- “too hard to find people to do things” — organizational debt
- hard to learn, monolithic architecture
- poorly documented
- long compilation times, memory requirements
Looking at it, we realized a few things:
- in past meetings, we’ve discussed how it feels hard to justify time spent writing docs. In general, we felt we needed some form of concrete incentive, similar to how performance optimization gets you that nice green bar. To that end we talked about:
- maybe we can set some specific documentation targets? For example, enabling
deny(missing_docs)by summer. - or identify some other form of doc coverage metric
- we might also block PRs that lower the doc threshold
- maybe we can set some specific documentation targets? For example, enabling
- in general, this seemed like a good topic to revist under a “compiler team governance and apprenticeship” meeting at all hands
In terms of the all hands, one idea for a possible outcome is to try and produce a “slew of technical design RFCs”, at least for certain key areas (e.g., the so-called MIR 2.0). We later softened this to a “technical outline plus a plan for who writes the full text”, where a “plan” includes who will do what.
One possibility is having “breakout sessions” where a smaller set of people go off to focus on some questions and then bring the results back to the group. It’s not clear how or if this will fit in the schedule.
We then turned to the topic of the RLS. Initially, we were contemplating starting out with some “review sessions”, but we ultimately decided to try and produce that material before the all hands. Ideally, for all of our major meetings, we’d have some kind of review material to get people in sync. Offline material can be enjoyed by others, and it’s nice for people to be able to review it at their liesure.
When it comes to the RLS, we decided to take a “tech first” approach – basically focus on the technical design we want, and then talk about the best way to get it (e.g., improve RLS in place, start over a la rust-analyzer, etc). matklad, xanework, and nikomatsakis held a separate discussion to settle on an initial agenda (topic).
For the “second most important topic”, we settled on “organizational questions”. The “root goal” of any organizational alternatives would be:
- be intentional about what we are doing: make sure we are making progress on the problems we think are most important
- grow the team
- maintain/increase quality
Some sample agenda items were how to handle factoring of compiler into libraries and how it relates to team structure. There was a consensus that having more focused subteams would reflect the reality that the compiler is too complex for one human to fully understand (unless they are eddyb).
I feel like we made some good progress on the concept of how to approach IDE discusson.:
- We will start by elaborating technical design and let that guide us the rest of the way.
- We will have some review materials available before the all hands
- We will have a short meeting (like, nowish) to try and create agenda
it seems like we consider organizational matters the next most important thing to discuss as a group. I feel a bit less clear on what the “agenda” will be, but maybe we’ll feel our way, or else maybe we should have some more pre-discussion about it. I would at least be up for trying to prepare a kind of straw-person proposal.