Agreed. I will only comment that I think CI WG is an excellent example of case (2). It's already operating as if it's a project, in every practical sense.

I'm not so sure about Language Interop. That sounds like either case 1 (do some specific work and when the projects have their Rust/Swift bindings, the task is complete), or maybe case 3 (bring people of interest together for planning, but the actual engineering work is done in the context of the individual projects). I kind of hope that LO doesn't end up with any permanent engineering artifacts that live outside the projects they are making bindings for, unless it turns out that they end up building some significant common infrastructure.

I'm not so sure about Language Interop. That sounds like either case 1 (do some specific work and when the projects have their Rust/Swift bindings, the task is complete), or maybe case 3 (bring people of interest together for planning, but the actual engineering work is done in the context of the individual projects). I kind of hope that LO doesn't end up with any permanent engineering artifacts that live outside the projects they are making bindings for, unless it turns out that they end up building some significant common infrastructure.

They will mostly be trying to work upstream, but there will be some engineering artifacts that will make sense to live in the project or be challenging to upstream for various reasons.

I'm not opposed to changing the structure, but I am opposed to "un-centering" groups like D&I. We should be making them more central to the foundation, not less. Sticking it off in some other category, while I'm sure doesn't represent the intent, might have the effect of less attention, less influence, unless we specifically make it otherwise. In my opinion, categories for the sake of categories are not useful - there has to be a reason moving things around would benefit all groups.

I think it's exactly the opposite. D&I is the classic WG because it's not making code, and it's not just people with a common interest. It's doing real work that is representing the foundation. This re-centers D&I by moving away the things we've classified as WGs but they really aren't.

Based on past discussions, I believe the consensus seems to be:

• Move the CI Working Group and ASWF Language Interop to be projects ( propose both at Sandbox, subject to Incubation requirement review )
• For Long Term Working Groups, allow them to appoint a voting TAC representative.

TAC members, please share your thoughts.

CIWG (which I propose be renamed to something akin to "Tooling and Infrastructure") doesn't feel like an experimental sandbox project with a potentially shaky future -- they've been a vital resource and mature code+group for years. How much are they lacking from the incubating (or even adopted) requirements? Is it something that can be quickly patched up before we convert them to a project, or can we convert them subject to fixing it within a few months?

I also still would like to better understand the argument for why language interop is a project, instead of being a WG whose code artifacts are parts of the projects whose bindings they are writing (with any common components they need to write being owned by Tooling).

PR #922 adds the language for this change. Please review and we can approve at the 1/8/2025 TAC meeting