---
title: "Meetup 2024: Handling concerns"
tags: ["T-lang", "design-meeting", "minutes"]
date: 2024-09-10
url: https://hackmd.io/M1J97zPIS1-ip8OKMDfQEw
---

# Meetup 2024: Handling concerns

Niko: Are we using / leaning on blocking concerns too much?

scottmcm: Agree that this is the thing people use because that's what we have.

TC: I see people outside the lang team who want to make a proposal look to the lang team and figure out who they think is the most likely person to raise blocking concerns and then tailor their proposal accordingly. That's over-indexing on one of us and leads to worse designs. I tell people to focus on the majority of us. If the majority of us are enthusiastic about something and there's one veto, that's our problem, not the contributor's problem to solve. But I see burnout over this.

Scott: Thinking about a case where motivation felt weak but no one felt strongly enough to put a concern. Better than leaving checkboxes unchecked; but the gap between "rfcbot concern" and "rfcbot reviewed" is huge.

TM: need processes that support the decision making you want to have. Having a single "hammer" (or lever) be this unilateral "concern" is either a bad lever or a bad sole/initial one.

FK: TC elaborate, has the "catering to expected concerns" ever been a successful strategy?

TC: I've seen us do it ourselves, e.g. "dirtying up a feature up a bit" when the majority wanted something to overcome a blocking concern. E.g. Linting against use of AFIT, refinement, RTN. In terms of external contributors it feels like a burnout formula because people feel like they're subject to some unknown/opaque machinations.

FK: It seems like there should always be a champion on the team who can navigate these. It's very hard to come up with something that everyone on the lang team likes; easier to find a champion. (Though that does pose risk of overloading one or two individual T-lang members with championship requests.)

TC: In theory yes. In practice I see even plugged-in people having trouble.

Josh:

- "vibe check" process for people outside the team to get a vibe check from the team?
- Having things smaller than a blocking concern, or not being so quick to jump to "is this a blocking concern or can we ignore you".
- Could the new process help here, in which we can start a consensus check / FCP-equivalent process immediately, where consensus involves a descriptive keyword and we all have to use the same keyword to reach consensus?

NM:

- "Is this a blocking concern": Agree there is something there, a connotation of "do I have to care".
- Stop energy can feel so discouraging that sometimes I have to put on "blinders" and avoid it for awhile.
- If a person feels like going into a session like this could be the end of the proposal altogether, they won't want to.
- Phenomenon where a concern over any aspect of the design stops work on the whole design
- May need to revisit new rfcbot process, not all the team was here for that.

Tyler: What process *would* make people feel heard?

TC: Looking more broadly, I'm skeptical of permanent blocking concerns. If I've put together my best case and I've been heard and the other lang team members aren't convinced, I think I'm probably just wrong. I can't imagine ever wanting to block progress on the language in that case.

There's a place for blocking temporarily. E.g., "I'd like to write something up about this and talk about it in the next meeting."

Scott:

- We have no tracking for concerns where lots of other people agree with the concern. Harder to resolve the concern later, because it's not clear when other people's "yes, I have that concern" has *also* been addressed.
- We don't have good way to keep track of design concerns vs implementation concerns.
- We either rely on RFC authors to act in good faith, or block the RFC until it's added.
- We should add things to the RFC more freely (especially unresolved questions/concerns or future work)
- Should we have a feedback mechanism for people making proposals, that gives them an idea of the level of support / strawpoll / etc. How far are we from consensus? Are we interested in the area and just not convinced by the specific technical solution?

Josh:

- Getting consensus-in-principle early, establishing the things we have consensus on and making blockers *as narrow as possible*.
- "The time to raise that concern was (some earlier point)." Upon raising that concern at some earlier point: "why can't we defer this until later and start the experiment?"
- Avoiding the "facts on the ground" problem.
- ACPs
- Moved to doing it in meetings so that people see it.
- Similar for compiler meetings.
- Unconf session on new process, talk through it and look at the state of the rustbot impl and try to give a go-ahead?
- What process *would* make people feel heard?
- A big problem is someone shows up with momentum and a design in mind and wants to avoid/remove roadblocks
- Need to understand where people are coming from, what the point of view is, the users they have in mind and how the thing they have a concern about would impact those users, etc.

Niko:

Sometimes the response is "I have heard and considered your point, I just don't agree or weigh it as strongly as you do"

"I want sharp designs, not rounded-off designs"

Have to be ready to lose sometimes too.

Josh: When people have been working off in private or private groups for a while, and have iterated for weeks/months/longer and ensured all their concerns have been incorporated, and then bring something to the broader team who have had a relatively smaller amount of time to process it, a concern being *understood* can take longer than a design meeting.

Niko: And conversely, the people who haven't been involved in the design from the beginning may need longer than a design meeting to understand the design.
Josh: :+1: Agreed.

Sometimes you have to trust the owners to some extent, and it's hard.. it's hard to fully delegate to someone.
Maybe we can delegate to someone else on the team.

FK: If we reach the point where we feel like we've made the case properly and we haven't gotten agreement within the team I think we would generally all agree that at that point we need to be willing to drop concerns. Concerns need to have a finite lifespan; TC was making this point and I think I agree.

Niko: I kind of want to flip the default, for designs that are well fleshed out enough. I want the onus to be on the person who raised the concern to have a meeting and make their case – the burden of proof is on you.

JT: :+1: for the concept of people raising concerns being on the hook to be available to work through the concern. However, there's danger in a language team being in default-yes mode rather than in default-no mode.

Niko: I agree, that's why I said it has to depend on where the

TC: The person writing the RFC has the burden of proof of getting 2/3 of the lang team to check their boxes. That's different from the burden of proof of raising a concern.

FK: I want to echo that saying "the right time to raise a concern was X" is dubious... there's not an easy place to say when is the right time for something to be brought up. Sometimes we're glad a person pointed something out late. But the burden of proof needs to be higher the later we are in the design process.

JT: Yes, if we find a soundness concern five minutes before stabilization (or five minutes after), we'll address it even then, but if someone raises a *syntax* concern five minutes before stabilization that is almost certainly far too late.

SM: The right way of saying it is "this was discussed and resolved during the RFC". And if it *wasn't*, if it's new information, then we need to consider it.

TC: Happy example... RPITIT, lifetime capture rules, and precise capturing. Tackled that problem as a group, in many ways, including committing to the bikeshed. The only problem is that it went so smoothly that people looking at it from the outside felt like it moved at warp speed.

JT: Another good example was the match ergonomics design meeting (credit to substantial effort TC put in). The design meeting went well because the problem was broken down correctly where we could pin exactly where any concerns we had lie. It was really really easy to establish consensus around specific points, and drill into others that required more discussion to understand (and ultimately agree to consensus on).

NM: We invented the RFC process to solve the problem about coming to Linux mailing thread with a finished PR.

JT: And it seems like RFCs are themselves sometimes too heavy and we need a vibe-check mechanism that can run earlier than that.

Niko to follow up and present a summary of this discussion to the team.