- Hold regular design meetings where people can bring proposed designs or proposed areas and get feedback.
- Meetings are open to all. Key compiler team members are strongly encouraged to attend.
- Each meeting will decide the topic of the next meeting. To be selected, a written proposal must be available for review.
- These meetings can be on Zulip or on (recorded) video-conferencing, with Zulip being the preferred format.
- Major architectural changes to rustc are expected to be discussed in this meeting before landing.
This proposal is aiming to solve or help with a few problems:
First and foremost, a place for feedback. We are trying to do a number of ambitious design efforts, and I feel like we often hit cases where it would be really useful to be able to bring interesting design questions to a wider audience and get feedback. Some recent examples I am thinking of:
- davidtwco was attempting to change the drop order for parameters in async-await fns in #54716. This was harder than expected, suggesting that some refactoring to HIR might be useful.
- Zoxc is looking into simplifying the lifetime setup, and we're having a hard time deciding whether to land the PR.
Second, self-documenting processes. Right now, we don't have much documentation about the design discussions that led to different parts of rustc. In my ideal world, we would have rustc-guide chapters and "design documents" explaining how things work. But a step towards that direction is just having some sort of place where we can bring high-level designs and talk them over, thus leaving a sort of paper trail.
Third, simplifying the review process. Reviewing architectural PRs can be quite challenging right now. One often has to infer from the PR what the overall design is, to start, and then decide if it is a good design, and whether this may impact other people. If you went into the review process with some idea what the PR was all about, and already knew this was a direction we wanted, it would make reviewing a more straightforward proposition.
For a meeting to take place, we have to have a "meeting proposal". This is a document that describes the subject to be discussed. It should lay out a possible design and give background material. It is expected that all people attending the meeting will read this proposal before the meeting starts. It doesn't have to be super long, but it should include links to any material you would like people to review before the meeting. It should also be specific enough that we can have a good idea which people ought to be in attendance.
We will maintain a shared "pending meeting doc" that contains two things:
- a list of "pre-proposals", which are very short summaries of a design idea, typically just a few sentences.
- a list of "meeting proposals", which would be links to the the elaborated documents described above.
Anybody can submit ideas to this list, presuming they have done the required preparation work.
The list of pre-proposals are there as "feelers". The idea is to leave some thoughts about an idea and to get feedback on whether it is worth the effort to prepare a full meeting proposal.
We would reserve a regular slot of 1 or 2 hours. The meeting will follow the following format:
- First: decide agenda for next meeting.
- We will go over the pre-proposals in the pending meeting document and try to decide which ones seem like questions worth covering.
- We will select one of the full meeting proposals to cover in the next meeting.
- If there are no full meeting proposals, then the next meeting will simply be a short sync
to review the list again.
- Note that the meeting proposal must be on the list by the start of the meeting, which ensures that it is available for a full week for others to review before it is discussed in depth.
- Second: clarifying questions
- People can ask clarifying questions regarding the proposal.
- Third: detailed discussion
- Review the question at hand and key design points.
No. I think there is always a place for "exploring" to find the design through coding. But when we open such a PR, we might simultaneously schedule a design meeting, and hold off on reviewing the PR until we've had time to agree on the architecture at a high-level (this will also make reviewing easier).
I would expect weekly, particularly given that it can be a "no-op meeting" if there are no pending proposals from the week before.
I would expect 1 to 2 hours.
I'm inclined to try Zulip, but perhaps we decide on a case-by-case basis. If using a video service, the meeting must be recorded and posted to a channel.
My intention it that working groups will also submit proposals to this meeting for one of two purposes:
- because they want to make changes that effect other parts of the compiler
- because they want to make others aware of the architecture they are building and get feedback on it