Evolving our working groups program

[jmertic]

Please share any additional details on this topic

As we have worked through some of the annual check-ins on working groups, we have working groups that fall into one of three categories...

1. Time or deliverable bound groups, which is in line with the initial vision of working groups.
2. Working groups that start developing out IP and/or engineering artifacts, that likely are closer to a project ( ASWF Language Interop is a good example ).
3. Groups that are more "special interest", which establish a forum for ongoing sharing of information or other collaboration on a particular topic ( D&I WG is a good example here )

Detail what actions or feedback you would like from the TAC

It would be good to have a TAC discussion to review the state of working groups, and see if any changes should be made. Some thoughts from discussions...

• For case (2) above, should those transition to become Sandbox projects?
• For case (3) above, should perhaps we establish a "Special Interest Group" program instead?
• Right now, Working Groups have no voting representation on the TAC. Should that be changed?

How much time do you need for this topic?

At least 30 minutes

[lgritz]

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.

[jmertic]

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.

[carolalynn]

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.

[lgritz]

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.

[jmertic]

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.

[lgritz]

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).

[jmertic]

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

[jmertic]

@yarille to run vote to approve change in #922 via LFX Voting