T-spec meeting 2024-03-14

--- title: T-spec meeting 2024-03-14 tags: ["T-spec", "meeting", "minutes"] date: 2024-03-14 discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-03-14 url: https://hackmd.io/X9QrkhwNRCeaOlRiHy2Xog --- Attendees: Joel Marcey, Eric Huss, Connor Horman, Monadic Cat, Mara Bos, Lukas Wirth, Felix Klock, Pietro, TC Potential Agenda: * Spec Stakeholder Roles * PR and Issue Review Policy * Additional Content Topics for Spec ## Spec Stakeholder Roles Joel: In the lack of having Project teams do written work, how do we as a spec team do work and get reviews efficiently from the stakeholders? Connor: Teams of the Project have the true authority. Split stakeholders. Felix: Agree with Connor the teams in the Project have the true authority. Bias towards readability to the reviewers. Mara: Stakeholders so far are the target readers/users of the spec. The other two are the experts and those with the authority. (And authority does not necessarily imply expertise.) Felix: Matters of fact vs. matters of content presentation. t-lang is an arbiter of disputes between t-spec and expert teams Mara: The writing part is the least amount of work. Most is research. Those with authority are those with the least bandwidth. Experts have more bandwidth, since we are only asking them for one thing generally. Joel: How do we handle core structural issues. e.g., code vs. prose? Felix: Lean towards presenting the way expert teams want. e.g., if opsem wants more code-oriented spec, draft something like that. Connor: Agree with (part of) what Felix says. t-spec is in charge with the actual presentation. Other teams say what Rust is and t-spec determines how that is said. Disputes between t-spec and expert team on the actual rules, expert team always wins. Mara: t-spec is not unique in how it works. Works like thep project. Work in public and pay attention to things that are controversial. TC: As a meta-concern, it feels as though we're approaching this in a very "waterfall" manner where we're trying to predict all of the problems we'll have and make decisions and craft policies for each of them ahead of time. It could be better to just go forward and accept that we'll run into unanticipated problems and to deal with them as they happen. Then we can make decisions and craft policies on the basis of concrete situations rather than based on hypotheticals. Mara: jpg analogy. Work in blurriness and get sharper. Instead of top down. ## PR and Issue Review Policy Joel: What is the policy of how PRs and issues are accepted and merged? Eric: Yes, fits into the stakeholder conversation. What is the authority line? Connor: If it is substantive content, then Project teams need to be involved. If it is style or other things, then the t-spec has the the authority. Felix: Agree with Connor. Trust t-spec team to make the right calls on issues and PRs, and when experts need to be brought in. Eric: Let's say Mara is working on lexing. Would it be up to Mara to bring in the experts to pull into a PR or issue? Felix: Yes. And reviewers should know when outside experts should be brought into validation. Eric: Is it 90% experts and 10% t-spec validation? Felix: Trust members of the team to aquire expertise (when necessary). Mara: Experts and authority difference. Minimize work from teams with authority. TC: If merging to master is not the indication that something is approved, then what is that process for tracking what has been or needs to be approved by the relevant team? Pietro: Add a warning to the top of the page. Felix: The vision doc has content about this. Connor: Main branch vs. dist branch. It goes into the repo once it's been ok'd content-wise and had expert loook at it, then dist branch once it's approved by the authorative team. Mara: For now, everything is in draft status. To merge a PR, an expert needs to review it. And then much later have a team officially approve it. Pietro: Strongly recommend not messing with git branches. TC: These seem to be these questions we're discussing: - To what degree do the T-spec members build expertise to write chapters versus relying on other experts? - What are the standards for merging to master? - If merging to master does not mean that a team has reviewed it, then how do we track what a team has or has not reviewed? - One option is that we use another branch to track that. - Another option is to tag inline what has or has not been reviewed. - What do we call "the spec"? Is that what we've merged to master or what has been approved by the relevant teams? Mara: Those sound roughly right to me. Felix: Bias towards merging. But having a mechansim (e.g., tagging) to ensure at some point something should be reviewed. Mara: Make sure we are confident on something and then go ahead. Add notes to document if needed. TC: One option is that we could make the approving teams responsible for merging content about their sections into a branch that represents what has been approved by the teams. If the teams would be willing to accept this responsibility, it could help with moving things along quickly, as this work would then be explicitly "on their plate", creating perhaps better incentives for giving it priority. Felix: We should file issues about the open questions here, i.e. the points that TC outlined above. (The meeting ended here.) ## Additional Content Topics for Spec