---
date: 2025-05-22
url: https://hackmd.io/rcgjbxvtS46QEH5HqsEY4Q
---

# 2025-05-22

People: nikomatsakis, Josh, Tim M, Jack, TC

## Agenda

* Hello
* RustWeek observations and debrief
* Plan next steps

## Notes

### Hello

FYI, Niko not available next week.

Welcome Pete!

### RustWeek observations and debrief

Jack: People outside the project seem very excited about \[the vision doc\]. I didn't talk to very much project members about it. But we had some good interest during the coding session.

Niko: One of my takeaways was that we should ask more or different questions. I wanted deeper drilling down. One of the tricks that I was advised by Holly was like "tell me about the last time you mentored someone, what problems did they hit" and then compare to "was that normal, or did it vary"

Tim: I wondered if you do have a list of things you want to investigate, because the brief currently is that we are going broad. It sounds as though you are quite intent to go deep into specific things. The other thing I heard you say is that we're hearing things we already knew, and that we were leading people or confirming them. I am pretty guilty of that for a slightly different reason, I'll try to support what people are saying so they feel as though I'm building a rapport with them, and to try to determine whether or not I've understood things correctly, but I do like the idea of essentially having some specific things we are investigating and that might make decisions more targeted.

Niko: I do think validating vs steering is a fine line.

Jack: We're really missing people that don't use Rust. Particularly people who tried Rust and completely failed. And I think that's going to give us the best insight into things that we haven't heard before. When we hear things from people who are using Rust, even if parts were hard, they eventually got over it, which is why they're still talking to us. People who don't use Rust because they don't think they should and/or who tried it and they couldn't feel like it'll give good data.

Josh: This may be something to enqueue for later but another item that seems closely related is how much we are synthesizing into a vision and how much we are documenting the results of the input we got. It seems like the original vision of the team was talk to a bunch of people and then write a bold vision for Rust that solves a bunch of people's problems. I wonder if there's a useful intermediate step which is to talk to people, write down shareable summaries of their feedback, not violating confidences, but just saying 'this is what we heard'. Then taking the result and saying "ok, what bold visions of Rust would address the problems we see as the most important". This has the advantage that people other than us can write visions and/or make alternate proposals, solve problems we didn't think were important enough, etc.

Jack: This is what coding *is*, right, we take what people say, distill it down into some themes that are present across interviews and people, and then we can quantify that based on how often it occurs, etc.

Josh: Yes, I think you're largely right to the extsent I understand the coding process, but I think we should consider the output of that process to be an important work product rather than an intermediate one we don't show to anyone. I see value in publishing a summary that can be used to write subsequent vision docs. It feels like it rhymes with no new rationale. We are showing our work.

Niko: I've probably said contradictory things, but I'm totally aligned with that. It's always what I've been looking for out of this. Publishing intermediate documents and summaries would be useful. I'd be happy if that's all we ever did.

Josh: I wonder if it would help for engaging more people to narrow down the tasks. Conversations, coding, writing a vision, are different folks.

Niko: I'd expected most people to drop out regardless, because that's always what happens. Nonetheless, I do take your point. I'd particularly separate out the summary. I'm opposed to the idea of a singular vision doc -- even though that's what I called it -- because it's something that we'll have to discuss incrementally. That's what I've been trying to get at with the north star documents. Maybe we should in fact rename this.

Tim: So, working back from the purpose of the doc, it's to inform project goals. One thing that does concern me is that this research process has proven to be laborious and difficult to repeat. We couldn't have this level of effort every year. One of the concerns I have to bring back to the takeaways from RustWeek is the risk that this doc will be a point-in-time thing which is quite quickly stale. There were a reasonable number of project members, let's say 3 to 4, that the vision doc itself probably wouldn't affect their participation in the project, because they're working on things that interest them. There were also the opposite, like, it'd be really nice to fit within a framework and feel as though we are working together. So there were two main views about the usefulness of the process, but one of the concerns is that it will reflect Rust at 2025 but after 3 years wouldn't be useful as a resource.

Jack: If we do it well I don't think it will become immediately obsolete. We will be listening to what people are trying to do, not just now, but where they are going. When we release the vision doc RFC or whatever it is it won't immediately happen. Updating it incrementally becomes easier because we have things that we thought were true and, if we do it well, it should be encompassing, not just what is true, but what is not true, so follow-up we can say, do these things still hold? I'm not so worried that following up will be hard or not useful. As far as whether or not project members will care or be influenced, I think the short of it is that there will be some level always of people that don't fit into a greater plan, and that's ok. That's the nature of how the project works. I think it will influence things like project goals and company investment. Maybe a company says "oh you recognize that interop is a problem let's give you some developer time to address that". So directly, maybe not, but it could influence teams as a whole to say, we're going to spend X amount of time working on things, so over the longer term. I'm not so worried about every person being aligned on the vision but more so that it will actually infleunce things over time.

TC: Here's one challenge that stands out to me. We're essentially doing focus group testing here. Usually when that's done, there's a set of specific questions that the client has that are trying to be answered. E.g., "can people use the product to accomplish X task in under 5 minutes?", "can people figure out Y feature, or will they give up?" That sort of thing (though we'd necessarily be a bit less specific than that). Sometimes the questions can be more open ended, but then it gets more difficult. We seem to have been doing the more difficult one. I wonder whether focusing on more specific questions we identify in advance could be helpful. I'm curious what people think there and whether it would help with the challenges we're discussing.

Niko: That's related to something I was thinking about. I feel like we should use the data we've gained to try to refine our research questions to the most interesting areas. The fact that we haven't talked to industry partners -- companies -- is a gap that we need to address. At Rust Week, I had some conversations and collected some cards. I think it'd be useful to try to refine our research questions into more specific things we want to address and to try to drill more deeply into those areas.

Niko: As an aside, I talked with a company that said they have a tool where we can send them our notes and our audio recordings and whatnot and they deliver back a work product along the lines of what we want. We should follow up on that and see how it does. We should at least try it. They said they'd do it for free given the small quantity of our data.

Niko: What I would say is that what *I* want personally is to have more of the 'broad' conversations with companies and Rust non-users and start to identify the detailed questions we might ask of Rust individual users based on what we've gotten so far.

Tim: I think we should consider whether we have enough.

Jack: We sort of know what we're aiming for, right, 5-10 interviews per axis? Domain/company-size/experience? I think Holly told us that after that we start to hear the same things. We haven't done a great job defining our axes.

Niko: Here's what I'm hearing as a possible next step. We should have a notion of what is enough. We do have some notion, but we know that we're not there. There are big gaps in the set of people that we've talked with. The strategy Holly mentioned is to keep talking with people until you stop hearing new things. We've talked with two companies, Zed and Google, and they didn't say the same thing. That's not surprising, as they're pretty different companies. We need to talk with more companies. There's general adoption, but when I talked with people from embedded, e.g. ARM, they have different perspectives on the space. It seemed to me that there was data there that we have not yet captured. Any doc that doesn't try to capture the action in the embedded space is not a good doc.

Niko: I feel like there's a need to focus on the coding work. I'll look into this company. But it's probably also a job for a couple people to do.

TC: Regarding embedded, is there any role for wg-embedded there? I bet that James Munns would be interested in helping. I can ping him about this.

Niko: I like that idea. Maybe we should try to recruit some partners from embedded land to help us. I'd want to be cautious though about avoiding importing an agenda.