search

AcademySoftwareFoundation / tac

Materials and meeting notes for the ASWF Technical Advisory Council (TAC)
https://tac.aswf.io
Creative Commons Attribution 4.0 International
93 stars 29 forks source link

Evolving our working groups program #798

Open jmertic opened 4 weeks ago

jmertic commented 4 weeks ago

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

How much time do you need for this topic?

At least 30 minutes

lgritz commented 4 weeks ago

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 commented 4 weeks ago

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 commented 1 week ago

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 commented 1 week ago

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.