T-spec meeting 2025-10-09

--- title: T-spec meeting 2025-10-09 tags: ["T-spec", "meeting", "minutes"] date: 2025-10-09 discussion: https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Meeting.202025-10-09 url: https://hackmd.io/1DtwXsv2Q0GZof9wa8QedA --- # Spec meeting - People: - TC - Eric Huss - Josh - Pete - Jane - Sam Wright - tshepang - Sid A - Driver: TC - Minutes: Pete ## The FLS pre-RFCs FLS pre-RFC: https://hackmd.io/1Z0RF7x_Sc6yM2kx39rC0w FLS pre-RFC minimal version: https://hackmd.io/Ug7c8hZBQcmd5v_YetudSg (The minimal version was the original draft that later became the first one linked; the second link is a snapshot of this earlier draft.) ## Mission of today's meeting ### Possible items - Address/discuss some feedback which was directed towards the first revealed / further elaborated version of the pre-RFC ### Discussion of what to make of today TC: We don't have an agenda and Niko isn't here. Are we sure we want to still have this meeting? Josh: Should we aim today to discuss some of the offline feedback left while we're online? Try to figure out consensus on next steps towards a second draft. Tshepang: Should we all open the minimal version, which is less controvesial, and see if there are concerns towards this one? Josh: Many of the items from the longer document apply to the shorter one. TC: Are you sure? The minimal document does a singular thing of creating the FLS team and sets out a charter. Eric: May be difficult to discuss meta issue as much of the content added was supplied by Niko. Without Niko here seems challenging to resolve. Additions seem to increase scope to the point of making the formation of FLS team challenging. Josh: Applicable still to minimal approsal: "completion" of t-spec's mission. Minimal approsal still seems to shift responsibilities of what had been t-spec's team over to a new team. Josh: Without a clear picture of how there's a team with continued responsibility on alignment on technology and glossary, this seems to be challenging even with this minimal proposal. Seems to give a partial picture even with the minimal proposal, especiall given how the FLS has been a core focus of T-spec. TC: The FLS has not been the focus of the team. Maybe this is a difference in perspectives due to when we joined. The team supported Joel in coordinating bringing the FLS into the Project, but we've done nothing else in that regard. Pietro did the technical integration. I do the reviews and merge all the commits, but I don't consider myself to be doing that with a T-spec hat. Josh: There's been a subset of the team that's been actively working on the FLS. The rest of T-spec may not have been actively working on the FLS, but working on the picture that includes the Reference and FLS, and discussing processes and ability to contribute, etc. The team has also been working earlier on trying to help review things in the Rust Reference, but that fell by the wayside somewhat, and has been somewhat awkward in that the members of lang-docs are members of T-spec, and T-spec is interested in working towards the Reference being closer to a spec for Rust, but T-spec doesn't actually have responsibility for the Reference. Josh: The nominal goal of t-spec is for there to be (a) spec(s) for Rust. Currently there are two, with many discussions around how best to manage these. Settled for now on there being two it seems, with some discussions around how to align longer term. If there's multiple teams: FLS team, specs for Rust, documents for Rust, it seems there may not be enough of a focus. TC: There's been concerns around some of these things for some time. Resolving these things may take some time. Pete is out there talking to safety-critical community folks. Pete has expressed the usefulness of having a team for alignment internally within companies / organizations (Pete, taking notes, agrees). It feels like we're telling Pete to hold and wait till we resolve on the organizational questions even though that could take an indefinite amount of time. TC: It would seem better to me if we could decouple this to allow Pete and others in safety-critical community to get started with the FLS team. Sid: Question for Pete -- "What prevents you and a subset of Consortium to contribute to FLS?" Works with group that does allow for this to Reference. Pete: As TC noted, there's nothing which prevents this -- people from the consortium come and do this. The question is whether they can make the case to their companies to do this on work time. One of the things I've found in having these discussions is that having a team for this is attractive. This gives the companies and people some credibility within the Project and a seat at the table. E.g., this would give them an invite to the Rust All Hands. If they can show that there's some value in being a member of a Project team, that allows them to make the pitch to management. That's some of the feedback that I'd heard. Tshepang: Sometimes make claims for "what's good for FLS" based on "what's good for Ferrocene". Would like others to have their voice present. Currently only documenting 2021 as Ferrocene only supports this. Justifying the time for 2024 is more challenging from a work perspective. Would be good to have others than TC involved with reviewing, merging PRs. Josh: Is important that we get a broader set of people reviewing PRs as well as writing up PRs. Have not spent enough time within this team on how the FLS is validated and how to better get it integrated into Project processes; haven't reached conclusions yet. Josh: Believes it's important for the FLS to have a team to "turn the crank" and get the work done. Also important to have a team which is working towards aligning tooling / glossary to make contributions possible. Eric: Do you see forming the FLS Team would block the things that are important to you? Josh: Issue of Perception and Reality. From a Perception point of view, whether or not we say t-spec is wrapping up its work and there's now a team which doesn't have the responsibility of t-spec it can seem like the work has been abandoned. In Reality, if there's not a team which is responsible for alignment and bringing a single spec, then this could be troublesome; have seen some Project issues in the past regarding this (Pete: feel free to add background/history here if you're aware and would like to @joshtriplett) Eric: If there's a structure where t-spec doesn't have direct control in some way, there's concern? Josh: Not exactly "direct" or "control", but if there's teams like FLS Team and e.g. lang-docs and they don't have the responsibility of "make a Rust spec" this can be a challenge organizationally of Roles and Responsibility. TC: Is T-spec responsible for FLS maintenance? Josh: Nominally yes, but in practice currently no. t-spec is responsible for making sure "there is a Rust spec", but doesn't have direct responsibility for making the the spec themselves. TC: Would it be fulfulling its mandate today to create a team to maintain the FLS? Josh: For that particular subset of the problem, yes. But seems to abandon the vision to have a coherent spec or specs. Jane: Understanding objection of Josh: - charter splitting off FLS Team? - without a clear set of responsibilities seems challenging? Josh: Current t-spec has several responsiblities. Currently not doing great job at maintaining and making easy to maintain FLS. If carved out, not sure if what's left in t-spec gives a practical way to accomplish what he feels is the mandate of the t-spec team. Jane: Not sure it's impossible to stage those pieces of work. t-spec in its future state to do this work (e.g. alignment, deriving a single spec or multiple specs in a coherent way) could be something which is highlighted. Seems that FLS team being spun up is important for a way to get the work done for maintenance. Josh: Agree with all of what Jane said. There should be a way to outline a "final" structure, but at the very least there could be a clearly delineated area for the FLS Team and there's also an additional area which is the responsibility of t-spec. How the responsibilty gets split between t-spec, t-lang-docs, t-fls would be a clearer picture than only spinning up t-fls and leaving the idea unclear is better. Jack: Start by pointing out the obvious. We have the FLS. It needs maintenance. Making a separate team is the best way to do this. Everyone here may not want to / may not be equipped to be involved with FLS maintenance. Jack: Seems a bit unclear on what the Rust community wants / needs from the FLS or a broader "Rust spec". Some of t-spec's role seems to be eliciting / soliciting from the Rust community what seems valuable. Jack: There will be discrepencies between Reference and FLS. Someone needs bandwidth to do this. Whose responsibility? Reference team? FLS team? Having there be a t-spec team be ultimately responsible makes sense to him. Having the right structure which allows figuring this out makes sense. Josh: Agrees with Jack. Forgot to bring up obvious issue. If t-lang is obvious parent, but doesn't have bandwidth to arbitrate / coordinate differences between Reference and FLS, then this seems problematic. Seems to create structure which is set up to fail. If it were the below this seems more likely to succeed: - t-spec - t-reference - t-fls TC: My feeling is that such a structure would create problems and would be an unusual structure for the Project. Jack: Don't think we have another instance in the project where there are two separate products which are so intertwined and their purpose seems similar aside from the Reference and the FLS. Having t-spec elevate specfic day-to-day items and delegate them to a potential t-reference and t-fls team seems important. Josh: To a broad degree there's some working model that has been seen among libs team that's worked reasonably. The intention would not be to interfere with charter responsibilities, but own some higher level responsibilities. TC: It seems natural to me for part of the job of lang to be writing down the language. For many other languages, the language designers have also been responsible for writing it down. It would surprise me if this is a job we could either abdicate or "delegate" to the same degree that we do with things like style. I'd like to see more direct lang involvement. My view is that this would be useful for the Reference, for the lang team, and for Rust. ## from chat Chat J jane jane says:hullo 17:03 Eric Eric says:hello! 17:03 J Josh Josh says:*waves* 17:04 Sam Wright (Ferrous Systems) Sam Wright (Ferrous Systems) says:👋 17:04 J jane jane says:double up and do t-spec next week? 17:06 Pete LeVasseur Pete LeVasseur says:Is there a notes document today? 17:08 J jane jane says:@tc what does that mean for today's meeting? 17:09 Sam Wright (Ferrous Systems) Sam Wright (Ferrous Systems) says: https://hackmd.io/Ug7c8hZBQcmd5v_YetudSg this one? 17:12 J Josh Josh says:@Sam: No, not that one. 👍 17:12 Josh says:This one: https://hackmd.io/1Z0RF7x_Sc6yM2kx39rC0w 17:13 Pete LeVasseur Pete LeVasseur says:Thanks for sharing the links folks 17:13 T TC TC says:Minutes: https://hackmd.io/1DtwXsv2Q0GZof9wa8QedA 17:14 Pete LeVasseur Pete LeVasseur says:Apologies @TC, it's possible Niko and myself overwrote the original one without forking 17:14 T TC TC says:Pete: No worries; it's what I expected; it wasn't a problem. 17:18 J Josh Josh says:@Jane: Can you post a link to the structure sketch you made recently? 17:30 Josh says:+1 for getting a broader set of people looking at PRs (and writing PRs). 17:37 J jane jane says: https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Path.20forward/near/541547744 17:38 Jack Jack says:Sorry for being late, was in a different meeting 17:43 J Josh Josh says:👍 17:47 Josh says:👍 17:50 J jane jane says:so you're saying josh is you would prefer to try to charter both t-spec going forward and fls but you wouldn't object to chartering fls and explicitly committing to figuring out the charter and continuity for t-spec/it's responsibilities going forward 17:50 J Josh Josh says:And explicitly declaring some of the responsibilities we expect that it has, In the same document, and signed off by t-spec and t-lang. 17:51 Josh says:s/interfere/coordinate/ 17:55 Josh says:I'm not sure why "coordinate" became "interfere with". 17:55 J jane jane says:I fully agree with TC's point that healthy teams delegate responsibilities, not lend, but also I do think there are situations where the responsibility continues to live in a parent team while work and recommendations for decisions come from a subteam (e.g. the lang example, the intersection of lang and wg-async and how decision making works there comes to mind) 👍 17:58 J Josh Josh says:That's a good example. lang and libs-api both treat wg-async as a set of experts and people doing design, and pulls them in often, and still ends up making decisions about the overall language. 17:59 Pete LeVasseur Pete LeVasseur says:FYI that I've got a meeting at noon 17:59 Pete LeVasseur says:Will have to drop maybe one or two minutes past 17:59 Sam Wright (Ferrous Systems) Sam Wright (Ferrous Systems) says:Yep, I gotta duck out also. 17:59 J jane jane says:in this situation I imagine individual editorial authority for fls and reference living in their subteams but resolving conflicts in their understandings of the language would continue to live in lang (or in a spec subteam if lang wanted to delegate that responsibiility) 18:00 jane says:but I also expect those decisions to be made with the mutual consent of lang+fls+reference 18:00 jane says:there should be no "decision over" relationships, it should always be "decisions together" 18:00 jane says:and this ties into my strong belief in shared membership of teams and consent decision making 18:01 J Josh Josh says:(To be clear, I think lang needs to roughly triple the amount of time its members need to spend dedicated to Rust every week. If we can get consensus on that then we might suddenly have this bandwidth. 😉 ) 18:02 Pete LeVasseur Pete LeVasseur says:ok... i really need to drop 18:02 J jane jane says:ty pete 18:02 J Josh Josh says:(Observation for the benefit of folks who have to leave at the hour: I think it's likely we're going to keep talking, but no decisions are getting made in this meeting, and we should take good minutes so we can continue the conversation.) 18:03 Josh says:Will message that to Pete since he already left. 18:03 Pete LeVasseur Pete LeVasseur says:can someone else jump in on notes? 18:03 J jane jane says:pete has been taking minute sright? 👍 18:03 J Josh Josh says:Sorry, typo. 18:03 Josh says:const-eval is largely more than a "consultant". 18:04 J jane jane says:wait 18:04 jane says:@Tc did i hear you right? "wg-async is a parent team of libs-api"? I feel like I must not have 18:04 T TC TC says:Spec being a parent team of FLS is more similar to wg-async being a parent team of libs-api than the other way around, in the ways relevant to Josh's point. 18:05 J jane jane says:ooh i see it was a metaphor not a statement of fact 18:05 jane says:comparison* 18:06 Jack Jack says:👍 18:06 Jack says:Is that true? Its certainly not true for the majority of types decisions. 👍 ❤️ 18:09 Jack says:I have had my hand up for a while. 18:16 J Josh Josh says:👍 18:19 Josh says:👍 18:19 Josh says:Jack: Full agreement with that characterization of T-types and T-lang. 18:20 Josh says:Some open questions: "form the FLS team *where*, in the project", and "where are the various responsibilities of T-spec". 18:24 J jane jane says:can we focus on one proposal at a time? It's much harder for me to track the state of the discussion when it forks 18:27 jane says:(joke) I propose we add a t-lang-launchpad 18:30 J Josh Josh says:(I'm going to have to drop for a meeting at the half-hour very soon.) 18:30 J jane jane says:yeah I'm sensitive to the needs of the FLS and think its fairly important to establish a team for them in some way 18:31 jane says:and want to unblock that 18:31 J Josh Josh says:So, minimal sketch of what the thing could say: "T-spec was chartered to ensure that there's a spec for Rust. T-spec is helping to charter an FLS team to manage the day-to-day responsibilities of the FLS and safety-critical work. T-spec is continuing to work on XYZ." 18:32 J jane jane says:fwiw t-spec only has an RFC, not a charter 18:33 J Josh Josh says:(jane, go ahead first.) 18:33 J jane jane says:im gonna share some feedback about this meeting in the zulip stream after, agree with frustration with the effectiveness of the conversation we're having here 👍 ❤️ 18:42 J Josh Josh says:(Stating this explicitly: I don't think "write one from scratch" is the path anyone wants, yes.) 18:46 Josh says:(no disagreement with that last statemen) 18:54 Josh says:*statement 18:54 J jane jane says:was gonna jump in with the feedback i mentioned earlier but I'll keep it to zulip