T-spec meeting 2024-05-02

--- title: T-spec meeting 2024-05-02 tags: ["T-spec", "meeting", "minutes"] date: 2024-05-02 discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-05-02 url: https://hackmd.io/ZJ5bsm-YRk2-VV4s_Y1KrA --- Attendees: Joel Marcey (needs to leave at 55 after for interview), Connor Horman, Eric Huss, Mario Carneiro, Pietro, Monadic Cat, TC, Mara Bos, Pierre-Emmanuel Patry, pnkfelix Potential Agenda: * Close out on [2024 Project Goal(s)](https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Project.2Fteam.20goals) * Core Library Fit ## 2024 Project Goals Connor: Proposal to specify 1-2 chapters of each of our top level topics. pnkfelix: The proposal is well-aligned to the overall Rust Project goal structure. We can coordinate the work amongst the various Project teams. pnkfelix: Niko's idea was to focus on a bit of Rust code that doesn't use a specific set of features. Focused. No problem with the goal as stated - there is a world where you can use a bit of code that we came up with and these specified chapters will allow that code to be specified. Mara: Pick the right level of abstraction to start. Make things deep and complete. Joel: Having a piece of code to point to will allow us to show people not deeply embedded in the spec process that we have specified something that will actually run with what we specified. Mara: Start with chapters that are not for this year. e.g., Macros, Traits. Pietro: Agree with Mara that any chapter we start writing is deep and complete. But any chapter we link to is deep and complete. Mara: Not sure it is a good idea to pick a Rust snippet and specify that snippet. Mara: Two extremes. A ton of partial chapters. Or one or two complete chapters. We may end up in the middle, but proposes we end up towards the second extreme. Mario: Another useful data point is estimated how much content is in any given chapter. Connor: Difficulty of a chapter could be subjective. TC: Maybe there's another way to look at goals. We could look at it in terms of outcomes on our *capacity* in addition to outcomes on the spec itself. E.g., right now, the closest thing we have within the project to a spec is the Reference, and it's maintained largely by Eric Huss by himself. Others contribute, of course, but he's the lonely reviewer. If we stayed there or ended up there again, we wouldn't have achieved our goals regardless of the outcomes on the document itself. So are there ways we could feed what we want here into our goals, in terms of increasing the number and attention of effective reviewers and contributors, or the effectiveness or frequency of teams reviewing work? (Clarifying questions.) TC: The thing people want to see out of us is *movement*. So the question is whether we can measure this sustainable level of movement somehow. E.g., if the compiler team only had 2 reviewers regularly taking PRs from the queue, that would be a disaster. We'd probably set a goal to figure out how to get to to e.g. 10 reviewers regularly reviewing PRs. That's what I'm getting at here. The goals should still be concrete. Mara: That might more sense for a team that is continuously maintating. Will be celebrating when someone writes an RFC and specifies a diff for the specification. Potential goal is having actual use of the specification in some manner. pnkfelix: Mara's goal is good, but not necessarily related to the Project Goal structure where we want people from the Project to help with the specification. Joel: Have a quantitative goal of a number of chapters written by the end of 2024. With milestones around process and use of the spec in real work. Connor: Actually has an RFC that can make use of the specification. Eric: It is very important to have an owner of the goal and the buy-in from the different teams. Connor: Multiple levels of owners potential. One for the goal. Others for the milestones. pnkfelix: Proposes Joel owns the goal and will need to decide whether to delegate or do all the work. TC, Mara, Conner: We second that. (The meeting ended here.) ## Core Library Fit Skipped due to time.