T-spec meeting 2024-04-04

--- title: T-spec meeting 2024-04-04 tags: ["T-spec", "meeting", "minutes"] date: 2024-04-04 discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-04-04 url: https://hackmd.io/ufFIrnJ0QOy6qltGV45Kkg --- Attendees: Joel Marcey, TC, Lukas Wirth, Connor Horman, Eric Huss, Pietro, Mara Bos, pnkfelix Potential Agenda: * Discuss PRs * Markdown Style Guideline: (merged) https://github.com/rust-lang/spec/pull/46 * Review Policy: (merged) https://github.com/rust-lang/spec/pull/51 * Semantic Issue Labels: https://github.com/rust-lang/spec/issues/52 * Pushback on spec progress and where we go from here * pnkfelix/eric: revisit testing policy q? ## Markdown Style Guidelines [Merged](https://github.com/rust-lang/spec/pull/46) without comment. ## Review Policy [Merged](https://github.com/rust-lang/spec/pull/51) without comment. ## Semantic Issue Labels [Issue](https://github.com/rust-lang/spec/issues/52) Connor: Follow the format of what is done in the entire Rust Github organization and its projects. Let's be consistent with the rest of the Rust project. Example: https://github.com/rust-lang/rust/labels/ Connor: `I-unclear`, `I-spec-hole`, `I-defect` are the recommended labels for indicating specific issues with the spec content. Also potentially we can have `A-rule-id` or `A-chapter-id`. TC: As in other areas and with other teams, it'd be good to follow the norms of the rest of the project and to use the existing names and labels used elsewhere in the project. **Joel: Will take the action item to make the current labels more Project friendly.** Felix: The number of labels can be overwhelming. Finding the corresponding labels may take a while. TC: We should certainly add these lazily rather than eagerly, and it'd probably be better to look at the team repositories rather than the main Rust repository as the best place to start. Connor: Recommend looking at the unsafe-code-guidelines label list, it's similar to what the spec repo is for. Eric: What does `I-` mean to you? Connor: The `I` stands for issue type. Eric: But it used to stand for importance. pnkfelix: Does the reference have labels similar? Eric: Not really. **Eric: Change `I` to `C` for Connor's proposed labels?** Connor: No issue with that. ## Review Testing Policy pnkfelix: A lot of infra that goes into the existing rustc test suite. Inline testing of spec examples could go into the rustc test suite, but that may not make sense. See value of having our own local test suite. Easing position of having our test suite being part of rustc (i.e., having our test suite being a subdirectory) Mara: Talking about documentation tests and unit tests. Not one test per rule, most tests will test several areas. Eric: Tests will have annotations similar to Ferrocene. And eventually the spec will be embedded in the Rust repository and will follow the same process as the reference. Connor: We do not have to embed the full UI test, like around diagnostics. TC: It probably would be nice to have the revisions feature from the Rust test suite. pnkfelix: Look at how cargo and other testing is done so that we are not completely reinventing the wheel. We don't need to do a ton of research though on this. Trust the process. *Bottom line: Move forward with a stand-alone Rust spec test suite but in such a way that we try our best to not totally reinvent the wheel such that it may be embedded into the rustc test suite at some point.* Eric: Will follow up with some examples exploring mdbook tooling for this. ## Pushback and Moving Forward Joel: Receiving pressure about making progress. Uncertainties about the funding for the editor if there isn't visible progress to those providing the funding. But there currently isn't any indication that is happening. There is a concern that starting from scratch ("v0") is going to be difficult to make sufficient progress, especially since Joel is not an expert enough to write everything (and there aren't enough people stepping up to write content). As opposed to just copying something like Ferrocene and starting that as a basis upon which we build, which has a more visible display of progress. Mara: We should do a blog post from the spec team on our current progress. Mara: Since we didn't hire someone full time, i assume there is still some budget available? Mara: Sp does it make sense to hire someone who can do things that Joel cannot do, or has time for? Joel: When we originally opened the position, there weren't very many applicants. Mara: But that was full time, this would be part-time, or specific to some sub-section of the spec. Pietro: Hiring a part-time person would help, but not in the current state, since we are still deciding stuff. Hiring takes time, so it would be good to plan ahead so that can be ready when we're ready. Connor: Ask Council to ask Foundation for clarity on these roles, to avoid having outside influence affecting the project. Mara: That influence currently isn't happening.