---
title: "T-types organizational discussion"
date: 2023-10-09
tags: T-types, 2023-meetup-BRU, minutes
url: https://hackmd.io/MtfD8X9GRxqdfZeT8vxteQ
---

# Organizational discussion

## Background

* Review the [RFC](https://rust-lang.github.io/rfcs/3254-types-team.html) for context, then talk about how well we are meeting the mission, what's changed.

## Key questions to explore

* What is working well and what could be improved with functioning of the types team overall
* meetings: issues/how effective are they/further improvements
* FCPs?
* What things do we do that are missing from the RFC?

## Expected outcomes

* Topics for deeper dives in future meetings
* Principles by which we operate

## Notes, minutes from the meeting itself

Niko notes:

* Opsem scope was removed
* Interaction with spec?
* Subteam doesn't seem to mean much
* Handoff from lang to types has been a bit subtle, I'm sometimes struggling to decide which scope "feels right":
* Advising on how to address soundness bugs or other subtle questions that arise.
* Might be interesting to review recent lang-team triage meetings to decide whether handoff is happening when it should
* How is team following up on nominations etc?
* When a soundness bug is found in Rust's type system, the compiler team can contact the types team to request the bug be triaged and to prepare a fix.
* is this happening?
* Leads typically serve for 6 months to 1 year, at which point we will consider whether to rotate.
* hmm :)
* Deep dives, how are they going? Happy with meeting structure?
* In lang team, a nice thing we've been doing is using the deep dives to read RFCs. Should we consider something similar?
* CTFE
* where does that fit? how does that work?

## Questions?

### Leads: change every 6 months - 1 year: how are people feeling?

Also, might be good to better define the exact roles of the leads. There may be other roles to split those responsibilities (e.g. Project Manager)

Compiler team has the senior/junior model, which has worked fairly well. Niko proposes this.

Jack: Could have one lead be more organizational, one lead be more technically oriented.

NM: I like the ops team model. The leads manage the technical side. But the ops model spreads around more of the other work.

NM: I view leads as more project managerial anyway, though there is a bit of "if things go wrong, helping to sort it out".

Jack: I try to always prepare the doc for the planning meetings. For a while we were trying to get meeting minutes into the github.

NM:

Specific tasks outlined in the RFC:

* Leading and scheduling team meetings
* Selecting the deep dive meetings
* Making decisions regarding team membership
* General "buck stops here"-type decisions

Other tasks:

* Liaising with mod team for membership

Team membership:

* leads have context that they can't always share, so they need to make final decision (e.g., consulting with moderation team)
* also historically people haven't always been good about nominating others

Digression about compiler team and how decision making is hard, especially because of the broad range of the team areas. Not always a great way to handle cases where a subset of the team is an expert on some particular thing. Given a complicated issue -- can we allow some sort of explicit `+0` delegation?

What about as types team grows? Will we come up with something similar. Jack: it would be nice if e.g. contributors team could raise objections, like the lang-team advisors.

Becomes more relevant as the team grows, and you get people who are deeply.

Niko: I propose tabling but maybe this should be a topic for future, do we want subgroups etc?

jack: ok, so leads, if it is a project manager thing, and we are talking about project manager.

errs: let's not look for volunteers without the full membership. But we can ask in the abstract.

nikomatsakis: I'd be happy to see other people pick it up; I'm also happy to put time into it. There would be some value to write out the tasks in more detail. Do we feel the current NM
### Each initiative is responsible for preparing a short (1-2 paragraph) document in the leadup to the planning meeting with the following structure:

did not work out :) doing it at the start of the meeting now.

> - What was the plan at the start of the month (list of goals)?
> - What happened? (brief narrative)
> - What is the plan for this month (list of goals)?

We don't have that format, do we want to try to follow it going forward?

Jack: I had a plan to make a triagebot PR so we can make an agenda, I started labeling issues, tried to make it more automated... it'd be nice if we could just, a week before the meeting, have to automatically generate and get things filled out.

NM: We've tried various things and this has always been difficult. The list of initiatives gets long, maybe we need to focus it more narrowly.

CE: The working group structure doesn't necessarily map well to what work is underway.

NM: A bot could help here. People are reluctant to close someone else's initiative. But a bot could do this.

Jack: I'm not sure the list of initiatives is that long. And seeing the list helps us keep track of maybe what we should get back to. As long as we don't overburden ourselves by doubling the list, it helps us track what might need to happen.

NM: Writing progress reports does help, in my experience, to help push me to do the final 5% of certain projects.

Jack: What should we do?

NM: Maybe a bot that pings people in Zulip and then you could go to the issue and see the updates. Maybe on a cadence of once a week or once per two weeks to prompt people to publish updates.

Jack: It can be nice to have things in one document.

NM: This is the job of the triagebot.

Jack: It'd be nice if the tracking issues had comments as updates.

NM: That's how I imagine it.

Jack: +1, but someone has to do it.

NM: In the interim, we could do it by hand.

NM: Let's investigate if there is a Zulip bot that can schedule messages?

Oli: Who is going to do that?

NM: Not seeing one is a quick search. Historically, triagebot needed a cron functionality, and no-one has done that yet.

Oli: We use a GitHub action for this in Miri. It's scheduled to run on a fixed cadence.

Jack: I'll own this. But someone remind me.

TC: Can infra team add some kind of cronjob that runs triagebo, as triagebot already runs in the infrastructure?

jack: I'll figure it out.

lqd: Ask Jakub (kobzol) on infra team.

### opsem, const generics, and CTFE

Where does const-eval fit in?

Should update the https://github.com/rust-lang/types-team README to reflect reality.

### Relationship to rust spec

NM: Ideally a-mir-formality would be normative, spec writers would find out how to interact with that.

NM: It'd be nice if the spec gave requirements/invariants that something like a-mir-formality would provide the detail for.

CE: We should say what we think the spec should include or not include because we're the ones on the hook. The level at which you document something is a decision in and of itself.

NM: There is a discussion to be had.

### handoff from lang to types?

* I'm sometimes struggling to decide which scope "feels right"

NM: This is something I wanted to bring up. In T-lang, we sometimes kick things over to T-types. Is that working?

lcnr: Not clear distinctions -- we always ping the other team if there's an uncertainty.

CE: It'd be nice to know with more certainty when T-types can make a unilateral decision. There can be delay in nominating things for T-lang just to check.

NM: We don't have an official way to nominate with urgency. The ops work that TC has being doing has been a help here.

TC: People have been reaching out to point out when there are urgent issues.

NM: Can nominate and not block.

CE: That's probably what I should be doing.

lcnr: Does T-lang look at closed nominated issues?

TC: For T-lang, triagebot does not currently add those to the agenda.

CE: Hearing NM say this is what I've been waiting for.

NM: I feel it's within my power as lead to say this is the right answer.

### How is team following up on nominations?

NM: We don't have a triage meeting. We tried to do it async.

CE: We should be sweeping through everything that doesn't get attention.

Jack: I think we're getting better at this.

CE: We're actually pretty good at responding to P-critical-esque issues.

NM: In the planning meeting, we've been: 1) doing status on initiatives, 2) doing a backlog bonanza; trying to keep an SLA...

lcnr: Would hope we can get through all nominated issues every planning meeting.

NM: It'd be nice if T-lang nominations resulted in an automatic Zulip thread.

### Calls for triage meetings

TC: The calls for the triage meetings work well for T-lang. Is that something we'd want to consider?

(Discussion about the pros and cons.)

CE: I'm in favor, but we should discuss this with the full team.