---
# System prepended metadata

title: T-spec meeting 2024-10-10
tags: [T-spec, meeting, minutes]

---

---
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.
