due to shared membership of teams

One suggestion I've heard is to aim for everybody on a team to be on at least one other team to try keep the communication channels between teams denser. That might not be possible, but explicitly trying to have representation from other teams embedded seems like it could be helpful for a lot of them? In Libs for instance we have some Lang representation but it might be good to have more Compiler and Release representation too.

I don't want to specifically request or not request, but I think it is already true that we need to move past this as a core part of the strategy. It's simply not feasible for there to be overlap in a meaningful way between more than 2-3 teams I think, and it creates the unfortunate incentive for people to stay on a team because they are the last ones left with overlap to some other team, which IMO would be an anti-pattern.

I would prefer to move cross-team collaboration out of backchannels from shared relationships and more into clear, well-known pathways. Talking directly between teams is great, and should be encouraged, but if we want to make sure things are caught and handled by the right teams then doing so can't fall onto the shoulders of people who just happen to have shared membership.

I agree with @Mark-Simulacrum here. I also I fear that a rule of "at least in one other team" will make things harder for individual contributors with low time. Also, it might be that people gravitate to a set of teams, forming clusters.

I would prefer to move cross-team collaboration out of backchannels from shared relationships and more into clear, well-known pathways.

What would you consider an example of a "well-known pathway"?

For example, dropping by #t-libs on Zulip, or emailing the team. I would like to get us to the point where it would not be uncommon to loop in another team via these channels (rather than, for example, happening that one member is shared and so puts the issue on their other team's agenda).

In some cases it may be fine to reach out directly to some member of a team too, but I would like to make sure we get to a point where doing so isn't necessary - it puts a lot of pressure overall on that person to be around and available. (This RFC suggests a contact person; but that person can rotate, and then it may well be reasonable.)

Do we want to track whether a group exists within another or at the "top-level"?

So, my current thinking is that top-level teams will roughly have a folder within the github repo where these charters will be held, and we'll then place subteams within folders (potentially more than one level of nesting, I guess). The charter for the top-level team should also explicitly have a list of subteams under it, mostly so that there's a clear listing on a diff level - it's also possible the folder structure won't work out and this would be the alternative. I would expect subteam charters to make it pretty clear who their parent team(s) are.