---
title: T-spec meeting 2024-06-20
tags: ["T-spec", "meeting", "minutes"]
date: 2024-06-20
discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-06-20
url: https://hackmd.io/d-8LXh2NTASg7NF-zmZqNA
---

## Attendees

- People: TC, Joel Marcey, Eric Huss, Monadic Cat, Connor Horman, Lukas Wirth, pnkfelix, Pierre-Emmanuel Patry

## Meeting rules

- Minutes, driver: TC

## Review go forward plan

TC: Let's review the go forward plan from last week:

1. Adopt the Rust Reference today.
- Keep in our back pocket adopting the FLS in parallel as e.g. the "Rust Safety-Critical Specification", but don't do that today. If we later did that:
- Ferrous Systems would promise to keep the Rust Safety-Critical Specification up to date.
- The project itself would maintain its current processes; only the Reference would be updated by contributors when stabilizing new features in Rust.
2. Reformat one chapter of the Reference ourselves, using the mdbook extension Eric drafted based on Mara's proposed layout.
- Connor: Will take the action item to reformat: <https://doc.rust-lang.org/stable/reference/inline-assembly.html>
- Joel: I'll find a different chapter and take that.
3. Ask the Foundation to hire a technical writer to churn through the *other* 114 chapters or so and made the same transformation.
- Joel: We're hoping to have a contractor board by 1 July. The person we're bringing on will be fully spun-up on day 1.
4. Expand the coverage of the Reference, in terms of the subjects on which the FLS has some coverage but the Reference doesn't, by adopting the content from the FLS into the Reference.
- In general, narrowing the distance between the Reference and the FLS, starting from the Reference.
5. Work toward associating the tests in the Rust repository with chapters in the Reference.
- Reuse the FLS annotations as much as possible.
- Explore adding a separate test suite for the Reference.
6. Leave as an open question the plan for rearranging the chapter layout.
7. Leave as an open question the plan for setting out the timeline for the milestones we want to hit and the metrics for success.
- Joel: The funding for the contractor will go through the end of the year, so we should probably have milestones on this scale.
- Joel: End of October would be a good date for this.

Mara had to leave early (last week), but was generally in favor of this plan and moving forward, as long as Joel is happy with it.

Eric Huss, pnkfelix, TC, and Joel are +1 on the plan as described above.

Pietro is concerned it will take us longer than we might hope to achieve the goals of the plan, in terms of having a document that meets the criteria needed for the safety-critical community, but hopes to be wrong about that. He sees the plan to keep adopting the FLS as the Rust Safety-Critical Specification in our back pocket and to reevaluate this later as reasonable.

Connor is concerned that the chapter layout (of the reference) may not work for us long term and may require us to redo work later.

## Things we wanted to discuss in this meeting

- What concrete steps we need to take to execute that plan.
- The standards of review for Reference inclusion.
- The open items above.

## Next concrete steps

Joel: We'll be hiring the awesome person on contract.

Joel: I'm hoping to have one chapter reformatted by the meeting next week, but I'll let people know async if that's not going to happen.

Eric: I want to talk with Lukas and Pietro to talk about the test matrix.

Eric: We should also look at moving the mdbook extension that I wrote to the Reference.

Eric: We should look at what we need to change in terms of permissions.

TC: We'll make a PR to the Reference noting in various places that it is the draft Rust Specification.

Connor: We may want to rename the spec repo to `spec-team` and keep the policy documents there.

TC: +1.

## Standards of review for Reference inclusion

We'll maintain the reviewership standards of the Reference. Anyone on the spec team can review and merge a PR. We want to be sure that we understand the PR and that it's correct, and if we have any questions about that, or it's not clear that it's something that the lang team actually decided, then we pull in the relevant people or teams.