2019.04.12
Announcements
- nikomatsakis has opened a PR with a draft RFC on the compiler-team repository. This RFC describes adding a new level (“compiler team contributors”) to recognize people who have been contributing regularly. It also tries to document a few things about members etc. Please give it a read!
- eddyb is nearing completion on their work on the symbol naming revamp. It might even offer some performance improvements.
- nikomatsakis mentioned that in the wg-traits meeting on Monday we plan to discuss how the Chalk crates are setup and the work to refactor them to make them more friendly for the RLS etc.
Main topic
Our main topic of the day was a proposal to add a regular design meeting:
So this was our plan for the main topic today:
- After that we’ll talk about my proposal for a regular design meeting and perhaps also a bit about working groups and how we feel they are working, what’s could be improved, etc.
The goal of the proposal was to have a central place where the team can review designs and have design discussions. These discussions could have a few forms:
- In some cases, people might bring a thorny problem, looking for help in finding a design. (Example)
- In other cases, people might be bringing an existing idea for evaluation and broader discussion, looking to reach a conclusion. (Example)
In each case, there will be a proposal describing the question at hand and the goals of the meeting. The expectations for this proposal would vary depending on the kind of discussion. For “early stage” discussions, the proposal might be fairly sparse. (Perhaps like this example.) For meetings that aim to reach firm decisions, the proposals would be expected to contain more details; it would be useful to list things the author expects are hard to do and also points where there are design decisions to be made.
The expectation is that these meetings will help us propagate knowledge of what is going on through the project; they will help people get feedback on designs (right now, it can be hard to get people to make time to really talk out a design). Finally, they can help newcomers to get more familiar with things, since people can lurk in the meetings and soak up details (not to mention the paper trail).
While the basic idea of the proposal was popular, we wound up changing some of the details for how it would run. We settled ultimately on reusing the slot for the existing steering meeting (Friday mornings, Boston time) but making it weekly.
Every Nth meeting (likely 3 or 6) would be a designated steering meeting. The role of these steering meetings it so select the next N-1 topics that will be discussed (from a list of proposals). In between meetings, people can add meeting proposals to the list for the next round.
When we make these decisions, we would be trying to take a “global view”. In particular, we don’t want to be doing designs unless there are people who will put them into practice. This probably means that we will prioritize design questions arising from existing working groups, but we might also take up design questions that might become the basis for a new working group, as long as there are people who would want to take part.
We also spent some time discussing the idea of a mentoring or ‘internship’ program for helping “frequent contributors” make the jump to “compiler team member”. The designs that we discuss in this meeting would hopefully wind up detailed enough that frequent contributors can pick them up and implement them, even if the people making the design are busy with other things. Similarly, design documents can become the basis for rustc-dev-guide chapters.