T-spec meeting 2024-10-10

--- title: T-spec meeting 2024-10-10 tags: ["T-spec", "meeting", "minutes"] date: 2024-10-10 discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-10-10 url: https://hackmd.io/wfURode-Suq5gZ2-NjQJmw --- Attendees: Joel Marcey, Connor Horman, Eric Huss, Monadic Cat, theemathas, TC **Agenda**: * Reference conversion progress update * https://github.com/rust-lang/reference/issues/1614 * https://github.com/rust-lang/reference/pull/1545 if there's time. * Looks to be waiting on review by T-opsem, I can bump it over there. * What else is being worked on? * What can we improve in the process? * eric: Update on test annotations: * Help wanted with reviewing https://github.com/rust-lang/reference/pull/1646 * eric: Update on previews: * Help wanted with reviewing https://github.com/rust-lang/reference/pull/1647 * eric: Reviewing has been and will continue to be the bottleneck for all work. Are there any ideas on how to improve that? ## Reference Conversion Progress Update https://github.com/rust-lang/reference/issues/1614 Main discussion on where to put main section ids. As of now they are stand-alone with no associated text below the section headers. No blocking on this necessarily, but will follow up on subsequent reformatting passes. ## Test Annotations https://github.com/rust-lang/reference/pull/1646 Eric: Needs someone to review this. Eric: Shows some quantifiable summaries on test status. Connor: One inline test for every rule? Eric: Infrastructure in mdbook and rustdoc is not sufficient for that. Push back on a test for every rule in the reference. Can link to a test in the Rust test suite. Connor: Inline tests can provide examples to the readers. Eric: Hesitant to put examples on every rules because it would explode the documentation. Eric: Reminder, we can use compile test in our own repository and link to them. Eric: Examples to introduce a topic and then other followup examples where there may be some interesting and complicated parts. ## Previews https://github.com/rust-lang/reference/pull/1647 Eric: Adds previews to PRs so you can see the output. Eric: Would like to have a live website to click a link to view it. Eric: Wanted to use an S3 bucket to serve it. But there was push back on that. Eric: Could use GitHub Pages, but hesitant. Permissions. Increases the size of the repo. Connor: Could use GitHub Actions to avoid repo bloat. Eric: But where is the artifact stored? Connor: Maybe GitHub has a place for storage outside the repo. Connor: I can look at maybe using a repository_dispatch trigger for this. ## Improving Reviews Add explicit reviewers to pull request. In our case, the entire `t-spec` team. Help with back and forth. Identify what needs to be changed to make the PRs better quality. Could make changes yourself. `t-spec` taking the reigns to write more content. Technical knowledge is a constraint and a bottleneck. Not sure what can be done about that because that is a people's time issue. Connor: I can take technical reviews (of other's PRs), especially for opsem/consteval sort of thing. I can do that on paid time instead of just volunteer time as well. - Be judicious on adding reviewers to the PR outside the `t-spec` team if they think it will be helpful.