[TOC Meeting] TOC + TAG Leads @ KubeCon NA 2024

[mrbobbytables]

Date, time and location information has been sent to the TAG Chair email list.

Agenda

• Review / deep dive on the state of cloud native reports from TAGs (please reply to this issue with links to them)
• Review how TAGs can help with DTR/GTR

[TheFoxAtWork]

TAG Environmental Sustainability's State of Cloud Native

[srust]

CNCF TOC: State of the Ecosystem Assessment - TAG Runtime

[chira001]

TAG Storage – State of the Ecosystem 2024

[mnm678]

TAG Security 2024 State of the Ecosystem

[jberkus]

TAG-CS State of the Ecosystem

[eddie-knight]

TAG Security State of the Ecosystem

[roberthstrand]

TAG App Delivery state of the Ecosystem (Slight updates needed after the meeting).

[TheFoxAtWork]

The TOC and TAG chairs met to discuss the findings from the state of ecosystem reports. The TOC propose some restructuring of the TAGs and Working Groups, TAG Chairs raised valid concerns around redistributing work too much in some areas or too little in others. All confirmed there are more cross functional areas of work than previously that touch on multiple domains.
TAGS were asked to take the slides back (Karena will share) to their groups and discuss what makes sense.
Some points of consideration:

• Development and Workloads
• Compliance and Policy
• Chair mentorship for transition

Other items discussed
Standing weekly project presentation meetings across TAGs and invite the end users. 5 min preso.

Joint DTRs across TAGs for incubation and graduation and Triage

[angellk]

During the TOC + TAG Leads Meeting, the TOC presented a TAG Reboot proposal.

In preparing the proposal, the TOC reviewed:

• the State of the Ecosystem reports,
• current state of the TAG leadership,
• current TAG alignment to TAG charters,
• current TAG alignment to TOC requirements and asks,
• overall requirements of the Cloud Native ecosystem.

The TOC has asked the TAG leads to review the reboot proposal with each of their TAGs and Working Groups.

The proposed new working groups and topic areas as discussed are in this presentation.

The proposed new TAG structure is:

• TAG EPOC (Energy, Performance, Observability, Cost)
  • Optimizing Energy Resources
  • Observability
  • Performance
• TAG Infrastructure
  • Multicluster Management at the Infrastructure Level
  • Bare Metal
  • Infrastructure Lifecycle
  • Edge
  • Network
  • Service Mesh
• TAG Data + Storage
  • Data
  • Storage
  • Databases
• TAG Applications + Workloads (alternative name proposed: TAG Development + Workloads)
  • Application Development
  • Workload Scheduling
  • AI Workload Development
  • Multicluster Application Management
• TAG Application Delivery
  • GitOps
  • MLOps
  • Platforms
• TAG Runtime
  • Wasm
  • Batch
  • AI Compute
  • Special Purpose Operating System
• TAG Security (remains as-is)
• TAG Contributor Strategy (remains as-is)

During the TOC + TAG Leads meetings the following was brought up:

• TAG EPOC can be seen as similar to TAG Security and the assessments that TAG provides to benefit the ecosystem
• TAG Applications + Workloads may be too similar (and confusing) to TAG App Delivery - suggested proposed name: TAG Development + Workloads
• Compliance is a topic area that has a lot of sub-projects and overlap with other areas
  • There is security compliance and general compliance
  • Perhaps Compliance and Policy can be combined into a Working Group
• Working Group Health
  • Some TAG have working groups that should be closed (if they remained as-is)
  • TAGs should look at TAG Security and TAG Storage for low overhead WGs
  • TAGs should look assess whether a working group needs to be created or whether the work is better driven by a TAG Tech Lead
• TAG Leadership Terms
  • With the TAG Reboot, the oldest serving Chair and role's term will automatically come up for re-election
  • The current Chair may run again, as desired
  • With the chair ladder WG being finalized, the terms will be staggered
  • The chair ladder process will need to identify how the new chairs and TLs are trained and supported

Edit to clarify: The proposed structure is topic areas, not specific working groups.

[danieloh30]

Looks great to me! I agree with the similarity and confusion across 3 TAGs - TAG Applications + Workloads, TAG Application Delivery, and TAG Runtime. In my understanding, TAG Runtime aims to introduce the cloud-native runtimes(or VM, stack) to eventually deploy/run polyglot applications which means it might be better to name them with "TAG Application Runtimes" (maybe I'm wrong!) So it may be categorized into "Application Development" and "Application Platform (or Foundation)":

• TAG Application Development

  • Application Workload (Application Development + AI Workload Development)
  • Workload Scheduling
  • Multicluster Application Management

• TAG Application Platform (Foundation)

  • AI Ops (GitOps + MLOps + AI Compute)
  • Platform Engineering (Currently Platforms)
  • Wasm
  • Batch
  • Special Purpose Operating System

I'm not sure if there's a limit WG count in each TAG like max 4 WGs.

I'm happy to discuss this further if you have any questions. Please feel free to disregard my suggestions if they don't accurately reflect the original reboot intentions.

[raravena80]

Thanks for the proposal @angellk.

I think these look good to me:

• TAG Security
• TAG Contributor Strategy
• TAG Data + Storage
• TAG Infrastructure
• TAG EPOC

For the rest, I have a few questions on the AI (as in Artificial Intelligence) items and WGs:

• Could we define what AI Workload Development in TAG Applications + Workloads is? Sounds similar to MLOps (which is in another TAG: TAG Application Delivery), and there is considerable overlap with Batch and AI Compute (which are in TAG-Runtime)
• Also, MLOps is pretty wide, I see it as the intersection of cloud native and all these (but not limited): Notebook dev, data prep, DAG workflows, feature store, model registry (i.e OCI compliance), inference/serving, batch inference, autoML, HPC networking/filesystems/storage, scheduling, model training, model observability/trustworthiness/security, experiment tracking, etc -- Sounds like this spans multiple TAGs so we may need to associate the term with multiple TAGs or remove it altogether(?)
  • MLOps is also at the core of the CN AI Whitepaper and the CN AI WG.
• What's the plan for the existing Working Groups that will not be closed? Will they be independent entities from the TAGs? or will they be associated to TAGs (single/multiple) or will they be just associated with the TOC (or just CNCF in general)? or TBD?

Thanks!

[kdubois]

This is a great initiative and seems like a much more logical subdivision of concerns!

A few thoughts:
With regards to TAG Applications + Workloads, "Workload Scheduling" seems a little ambiguous to me. Is this referring to eg. jobs/cron jobs? If so, perhaps it would make more sense to move this to the Runtimes TAG.

In TAG App Delivery, shouldn't there also be a Continuous Integration workgroup?

[roberthstrand]

Based on feedback from various active working group and TAG members, and discussions with the technical leads and chairs, I feel that splitting up the working groups is not in the best interest of our group.

Ever since the meeting on-site at KubeCon, I have been trying to think what problem splitting the group up will solve. When I look at the now proposed two TAGs of Workloads and App Delivery, I would consider all of those topics (mostly) to fall under the responsibility of (in many cases) a singular team at an organization.

The way that I read this list, it seems to be a mix between areas of responsibility and current working groups. The working groups we have been created to solve different aspects of the common goal of the group, and maybe we should focus on changing the name of the TAG to reflect this rather than move groups across various arbitrary groups.

There is no way to split up the various domains without overlapping between them, and in that sense I don't mind there being a TAG Infrastructure. Having that group take care of "Multicluster management at infra level" does make sense, but moving app management away from our TAG will in my opinion make it even harder for people to figure out where to contribute.

As for renaming, I have a bunch of ideas, but I don't want to throw too much info into the discussion right now.

[chira001]

• TAG Leadership Terms

  • With the TAG Reboot, the oldest serving Chair and role's term will automatically come up for re-election
  • The current Chair may run again, as desired
  • With the chair ladder WG being finalized, the terms will be staggered
  • The chair ladder process will need to identify how the new chairs and TLs are trained and supported

We should take a few minutes at the next TOC call to figure out the logistics for automatic elections.

Currently the charter specifies that for existing TAGs, the TAG leadership presents candidates to the TOC for election. However, we are all aware of the shortage of candidates, which has led to the extended term times. Perhaps if we are to have elections in the absence of candidates nominated by TAG leadership, we may need to establish a simple set of nomination and qualification processes for TAG chair candidates. I'd be happy to propose some minor changes to the charter operating model to enable this if appropriate.

[leonardpahlke]

What are the reasons and goals of the restructuring?

• TAGs do not reflect the landscape
• Some TAGs lack engagement (leadership & contribution)
• more?

[salaboy]

Folks, I like the proposal to restructure the TAGs, I appreciate the effort there. But, being part of the Application Development WG and looking at this proposal:

- TAG Applications + Workloads (alternative name proposed: TAG Development + Workloads)
  - Application Development
  - Workload Scheduling
  - AI Workload Development
  - Multicluster Application Management
- TAG Application Delivery
  - GitOps
  - MLOps
  - Platforms

I feel that we will be splitting once again Platforms and Application Developers, which seems to defeat the purpose. I firmly believe that App Devs and Platforms should be together. It sounds like GitOps and MLOps are very close and also related to Multicluster Application Management and Workload Scheduling.

In my head, something like this make sense:

• TAG Ops (maybe another name)
  • GitOps WG
  • MLOps WG
  • Workload + AI Workload + Batch Jobs Scheduling WG
  • Multicluster Application Management WG
• TAG Platforms Enablement
  • Platform Engineering WG
  • Application Development and Developer Experience WG
  • AI Development WG

I totally understand that everybody looking at the TAG restructuring will have different opinions on the subject, so as soon as we make sure that WG collaborate between each other, the names and hierarchies should help newcomers to understand the focus of each TAG and WG.

Hopefully this makes sense @angellk @roberthstrand

[mbianchidev]

The idea of adding terms and restructuring is great, kudos!
I'm now going to provide a focused feedback on the TAG and WG where I'm more active in.

As active member of the WG Platforms, I strongly believe the WG (currently under TAG App Delivery) should become a TAG.
So, I kinda agree with @salaboy here, but my ideal outcome looks more like:

- TAG Platform Engineering
Platform Enablement WG (where people continue paap, paap-research and all the current subprojects)
Application Development and Developer Experience WG
MLOps WG -> Renamed "AI Platforms" and contains every non-data AI WG

- TAG Application Delivery
GitOps WG
App Development WG
Artifacts WG
Every other non-dead WG if any (they should be all afaik)

or

- TAG Platform Engineering
Platform Enablement WG 
Application Development and Developer Experience WG
AI Platforms WG
GitOps WG
App Development WG
Platform Artifacts WG

Maybe this rename scenario has too many WGs?

The rationale behind my idea is the following:
The Platforms WG is currently very active and having quite some sub-WGs and projects, so the interest is definitely there and we have the urge for more structure and resources.
We are also mature enough in our processes to be promoted as a separate TAG.

I also shared the outline of this idea (in person) with many members of the WG Platforms at KubeCon NA, plus @caniszczyk and @rochaporto (at KCD Denmark), receiving an overall positive feedback - nothing binding or anything but a sign that this new TAG makes sense from the outside point of view too.

[alolita]

Dear TOC,

The TAG Observability leads (chairs, TLs) were unable to join this discussion at KubeCon NA 2024 due to talk session conflicts.

The TAG Observability leads would like to discuss with the TOC, the suggested proposal of combining 4 areas (EPOC) into one TAG since these are significantly diverse areas and have their own areas of expert understanding. We would like to better understand how the mechanics of such a merger would work.

TAG EPOC (Energy, Performance, Observability, Cost)
Optimizing Energy Resources
Observability
Performance

Please let us know how we should proceed for this discussion.

[angellk]

Thank you everyone for the comments and feedback so far! The TOC is asking all TAGs to submit final comments by December 9, 2024, EOD.

[rajaskakodkar]

The overall structure looks good to me and my comments echo what @raravena80 has pointed out.

Additionally, I think that AI cross cuts all of the proposed TAGs and maybe there is an opportunity of a cross cutting TAG AI. The WG AI is working on efforts which touch security, MLOps, Workload management (scheduling), data (vector databases), observability (GPU monitoring), etc in some way or the other.

[ams0]

I believe I am expressing the concerns of more folks in the TAG Observability and TAG Environmental Sustainability for the merging of our communities; the merge will make the whole topic of sustainability disappear from the cloud native landscape altogether and make it harder to get our respective message across, plus very likely alienating the current members which will struggle to understand the direction forward. Moreover, reducing sustainability to just energy resources is missing the many other dimensions we need to think about when creating a sustainable future with our software; we will have serious problems interfacing with other communities (local authorities, academia, and more) if we drop the sustainability brand for an unspecified "EPOC" brand, I am afraid that the connections we have built as a community (2 sustaibability weeks, many meetups, presence at Kubecon) will be lost in translation.

I understand the need to rationalise, re-vitalize dormant WGs and TAGs, but I urge the TOC to reconsider, as our nascent community is just getting started in getting sustainability front and center in cloud native. Looking forward to more discussions, clearer directions (we are open to criticism and improvements, as always!) and doing our part in the cloud native commuinity.

[leonardpahlke]

Hello all,

We have been talking about the proposed changes in TAG Environmental Sustainability several times now. There is a long thread in our Slack channel with several folks commenting on the proposal. This is a summary of all discussions around this topic.

Overall we understand the need to make changes to how CNCF TAGs are currently structured and we appreciate that changes are being proposed in the first place. For us, the suggested change means that TAG Environmental Sustainability would be bundled together with TAG Observability into a TAG Energy Performance Observability and Cost (EPOC). We have several concerns with this proposal. We have also had a discussion with TAG Observability leads who share our concerns and they will share their feedback separately. We would like to propose a different structure for the above mentioned TAGs.

TAG Environmental Sustainability is driven by passionate volunteers that would like to contribute to making the cloud native and open source space more sustainable. Their motivation is not driven by cost but by a shared ethical responsibility. We are a very healthy and involved TAG and while we understand the desire to help other areas where the TAGs are less active, adding scope both dilutes the resources and will likely significantly diminish the current passion and involvement. We have reservations about changing a charter where Environmental Sustainability is not the main focus and we will lose people. We have spoken with many of the individuals privately. Even if we were to leave the working groups intact, we have carefully built a community around these passions and we will lose both momentum and members.

Sustainability is an overarching topic and no one can do this type of change alone. There must be drive and motivation in the community - the more engagement and motivation there is the more impact we can create together. We do believe that CNCF as a whole has a huge role to play in this change. If the work that's being done in the community to improve sustainability of the cloud native space, including CNCF landscape, isn't supported, encouraged and highlighted by the organizations like CNCF, it will be more challenging to gain progress, create useful resources for the community, and even to make larger community, like CNCF project adopters and end users, understand why we, as engineers, should care about the topic of sustainability, and what impact our decisions have on the constantly increasing amount of emissions the tech industry generates.

With support from the organizations that have such a wide reach like CNCF, we can gain more contributors, more opinions and from this diversity innovation happens. Innovation leads to new ideas and fosters passion to collaborate on more projects that can make an impact in areas like decreasing the sustainability footprint of CNCF projects. That's how the Green Reviews Working Group in the TAG ENV was formed and why it has progressed as far as it did in such a short timespan.

The TAG ENV grew since we started and earlier this year over 30 community members met on a very short notice at KubeCon+CloudNativeCon EU in Paris this year. Among TAGs, a meetup of this size is a great sign of interest from the community and willingness to participate and contribute to the TAGs' cause.

Cost is one of the reasons why companies care about sustainability and that’s a legitimate reason. However, cost does not reflect the motivation behind why contributors are approaching us. If we only think about sustainability from the cost perspective then we do not fully understand the subject and are closer to greenwashing than to finding actual solutions to the problem. Thinking about sustainability purely in the context of cost is undermining the level of impact and scope it has overall in the tech space.

Observability is one of the main areas we are looking into now. Most talks are about sustainability metrics, measurements or analytics. However, observability is only one facet. Data is the basis of all - without data you cannot build automation or continue with a more in-depth analysis on the subject. We are at the stage of gathering metrics, doing benchmarking and analyzing the data. Some projects already use these metrics. Sustainability is not Observability or the other way around. It’s not even in the same category. Putting both TAGs together is alienating both domains at the same time. Observability takes its own space and sustainability takes its own space too.

Energy is the primary abstraction for virtualized resources. Most topics we are dealing with now fall into the energy and observability area. But Energy is not Sustainability. Energy is just a metric we use to get a basis of data. Emissions are not Sustainability either but we use energy to estimate emissions to get closer to hosting systems while producing less emissions.

With all that has been said there may be the question what sustainability now means in the cloud space. Sustainability is a mindset, tools and methodology to building cloud systems mindfully. Because of climate change this is for now mostly focused on emissions and energy. But that’s not the end. Sustainability is about maintainability (repairing your broken tech), about adaptability, about using resources intentionally. Understanding the value that you generate with your systems while being mindful of the resources that you take to achieve that. The goal is not new to computer science. Maintainability has for a long time been a part of the software quality goals (ISO 25010). Resource utilization awareness is a newer topic that still is an addition to the general software quality goals. Initiatives like Kubernetes WG Long Term Support (LTS) are related to the sustainability topics that at the same time pose technical challenges. Sustainability is also about understanding the overall technical complexity which is a topic the CNCF space is struggling with. Sustainability is also about minimalism (K8s, K3s, K0s), i.e. running as little as possible and packaging only what you truly need to use. Sustainability is also about digital sovereignty, owning your technical stack and having the possibility to choose your partners and suppliers, as well as choosing the parts you want to own and maintain.

Putting TAG Environmental Sustainability together with TAG Observability into a TAG EPOC would be a sign that we, as a global cloud native community, have not understood sustainability. Sustainability is not voodoo, it's a technical challenge, it's affecting the technical space and we have all the power and motivation we need to push this topic forward, even though it may happen with smaller or slower steps at a time.

If we were to consolidate some of the TAGs our suggestion would be to put TAG Environmental Sustainability into a TAG Sustainability and Performance. TAG Observability and Cost could be ideally kept as a separate TAG or perhaps merged with TAG Infrastructure. Sustainability and Performance are more closely related domains. Sustainability is effective only when we build systems for performance, but performance shouldn't be one-sided. We need to approach it thoughtfully. That's why combining sustainability with performance makes much more sense and presents a great opportunity for the TAG to align more closely with its core principles and goals. Technical and environmental sustainability and performance would be part of the TAG, social sustainability would remain with the TAG Contributor Strategy and economic sustainability would remain with the adopters and the end-user tab.

We appreciate you taking the time to read through and evaluate our feedback on this change, and we hope that you will take it into consideration for defining the final outcome from this discussion.

Thanks,

Kristina, Marlow and Leo
On behalf of TAG Environmental Sustainability

[lianmakesthings]

Hi all,
I have been struggling giving appropriate feedback about this proposal as I was and still am missing context as to what the TOC is trying to achieve here. Without that, it seems a futile task to assess the success of this suggestion.
With that in mind, I want to address three problem areas that I see or have heard about from CNCF TAG and TOC members with proposals how these can be addressed.

1. Collaboration with the TOC
   The TAGs seem to currently not sufficiently support the TOC in their mission (more on that in the second point). From my personal perspective we in the TAG App Delivery have had very little communication or guidance from our TOC liaisons, who seem to take a more hands-off approach. We have monthly leadership meetings with the TAG chairs and representatives from the WGs. It would be immensely helpful for the TOC liaisons to start attending these to improve information flow to the TOC. At this time, all responsibility of communication flow is on the shoulders of the TAG, which poses quite an administrative burden. A two way communication flow where TAG representatives attend TOC meetings and vice-versa could alleviate this.

2. TAG should capture & enhance the ecosystem
   At this point the exact scope of TAG activities remains unclear to me. Since joining TAG leadership first as TL, now as Co-Chair, I have been mainly handling administrative tasks with little time for actual contributions to the ecosystem. Not only is this an issue in terms of understanding and facilitating growth within the ecosystem, it also makes the leadership positions less attractive (imho) to potential candidates.
   I am proposing to return the focus of the TAG to guiding and nurturing CNCF projects. I would also like to make it mandatory or at least a very strong suggestion for CNCF project maintainers to attend TAG meetings in their respective TAGs and/or otherwise engage in TAG activities (e.g. take part in project reviews). Being a CNCF project should not only be a label to be slapped onto your website, but also include a commitment to contribute to the overall health, advancement and sustainability of the entire ecosystem. TAGs could also regularly publish papers on the state of the ecosystem if they have the capacity.

3. Structure for Working Groups
   With putting the focus of TAGs on projects, I am also suggesting to decouple Working Groups from TAGs, at least in terms of direct oversight. Instead I suggest that Working Groups act independently from TAGs, as they often intersect/overlap with multiple TAGs already. In the TAG App Delivery we have been dealing with maybe a bit of a luxury issue that interest groups form around topics that then spin up Working Groups (e.g. Infrastructure Lifecycle, App Development). However this leads to two issues: 1. The scope of Working Groups is easily extended as they are tied to areas of interests, not outcomes and 2. Activity & momentum within the TAG immediately flows out to Working Groups which leaves the TAG and TAG meetings under utilized and most of the effort for TAG leadership is focused on managing Working Groups.
   With this in mind I would like to propose the following constraints on a new Working Group model:

• WGs operate independently from TAGs, with direct oversight of the TOC- They require sponsorship from at least two TAG leaders (co-chairs or TLs)
• Working groups should be formed around specific outcomes/deliverables and spun down immediately after this has been achieved
• Maximum runtime of 2 years. When this time has elapsed it should be reevaluated depending on what the issue is (lack of engagement, scope too wide, etc)

Additionally to the above points, we would also like to ask that each TAG (however they may be restructured in the future) receive a short tagline to elaborate on its scope and position within the wider Cloud Native ecosystem.

[jberkus]

Before we proceed on any reorganization of TAGs, I'd love to see a chart of:

1. Which projects would end up under which TAG after the reorg;
2. Which regular TAG members/leaders would end up in which TAG after the reorg.

I'm assuming that part of the goals of the TAG reorganization was to have a better distribution of projects and personnel. However, the resulting distribution hasn't been shared with anyone outside the TOC.

I will also point out that only about half the TAGs were represented at the in-person meeting. Has there been an organized effort to collect feedback from all current TAG leads? This thread doesn't count, because there's no reason for anyone not already tagged in it to know about it -- or to know that we're discussing CNCF-wide reorganization in it, given the thread title.

[jberkus]

@lianmakesthings several TAGs use Working Groups as permanent subprojects, because CNCF doesn't have a subproject concept. Implementing your WG suggestion would require adding a new organization level for subcommittees with long-term work.

Also, the CNCF previously tried having WGs which weren't under a TAG, and it worked out poorly -- those WGs ended up entirely detached from the organization. We'd need a way to prevent a recurrance of that problem.

[abangser]

Hi all, I have been thinking on this restructure and on the directive to think about how the TAG structure can support the ecosystem needs as well as the organisational needs of the CNCF. There is no doubt there are a lot of challenges with tackling something of this scale and that we are all “touching different parts of the elephant” as they say. With that in mind, I wanted to share two challenges I noticed from my perspective and how that leads to a suggestion that may be interesting to discuss.

First the challenges I have faced when thinking about how the TAGs structure support the ecosystem which creates a niggle with the proposed structure. In that it seems to present implementations rather than outcomes. If I am thinking in a DDD way around tech, I would think we can get more durable and impactful groupings based on business value/outcomes instead of layers of tech. Yet this newly proposed TAG structure continues to keep the current structure which describes a mix of implementations. And that leads into the second challenge in thinking about how the TAG structure can support the CNCF organisation. The TAGs objectives are clearly defined as supporting projects, yet (similar to what @jberkus raises) it is not always easy to know which TAG a project should be primarily supported by nor if they need to engage with a secondary or tertiary TAG for the right level of visibility, support, and improvement. In addition, I know we are struggling to grow and support people into TAG admin roles yet this proposal has 8 TAGs which is the same number of TAGs we currently have. While the improved alignment/topics may see a matching improvement in participation/leadership, I worry that it will be difficult to sustain for the same reasons as we currently see.

So in trying to support the key goals of the TOC with this TAG revisit, while also keeping in mind some of these more tactical challenges, I came to an idea that we could leverage an existing CNCF resource: the landscape. In this world we would only have five TAGs, one each for the categories (App Definition and Development, Observability and Analysis, Orchestration & Management, Provisioning, and Runtime). The TAGs would then manage and support the subtopics that are listed within their category on the landscape (e.g. Runtime would manage cloud native storage, cloud native network, and container runtime).

In reviewing this I can spot some things that may cause confusion but one big positive would be that any confusions could be tackled in a single place and then roll out to both the external facing landscape, and the internal organisation of TAGs. In addition there would be a concrete division of both categories and subtopics which enables a 1:1 mapping of projects to category and clear divisions of focus based on higher level domain objects.

One challenge I would like to echo from @lianmakesthings’s comment is that this may almost require space for cross TAG working groups that have only a sub 1 year horizon, specific output, and at least 2 sponsoring TAGs. While I know this was a challenge to manage in the past as @jberkus mentions, I wonder if we can learn from those experiences and with the reduced number of TAGs use this broader format to support the efforts discussed both for AI and Sustainability above as well as the effort I am most closely involved in which is Platforms.

[chira001]

A few observations and ideas based on the responses above.

1. We should start any re-org with a clear statement of the problems we are trying to address. I think there is some understandable angst and defensiveness because of this ambiguity. The TAGs are invested, and have all put time and effort into their communities, and change needs to be explained. Proposed action: lets be clear what is needed or what needs fixing, and loop the TAGs into finding a solution with the TOC. Ultimately the TOC is responsible for making the decisions, but getting buy-in is always easier if the reasons are transparent and the stakeholders feel involved.
2. We need to recognize that the TAGs are also voluntary and whilst we want them to be successful in terms of the objectives of the TAG charter (around TOC scaling, end-user/community, education etc ...), they are ultimately a community. We can't force a community on people - they need to want to do it, and ideally, feel appreciated and benefit from the work they are doing. The community is going to form around shared interests, common problems that need to be solved, or to deliver things that benefit their community. Proposed action: Don't try to force a square peg into a round hole. This is not a business, but a community, so we can't force organisation around outcomes - certainly not without the community wanting to do that ... which comes back to (1).
3. As time goes on, we have specific roles that the TOC needs the TAGs to do in order to scale, such as project reviews, security assessments, etc ... That means that TAGs need to be healthy and operational, beyond just the community - otherwise this impacts the work of the CNCF and the ecosystem that ultimately we are benefiting from. It also means we need clear plans of how processes will operate when TAG resources may be stretched - a TAG needs critical mass to be functional. As per (2), Community and SMEs organise around a shared interests/problems/benefits - but in an evolving landscape it is expected that different areas of the landscape will go through different maturity cycles. Ironically, when a particular area in the landscape is mature, the number of interests/problems/benefits naturally drops - and with that, so does the community participation. This can stretch the operational function of the TAGs. Proposed action: We should discuss potentially looking at a slightly different structure where we decouple the community and operational functions of the TAGs, allowing the communities to form a natural critical mass with the expected ebb and flow, whilst retaining the ability to perform the project reviews, security assessments etc ...

Although some of these challenges are not fun, they are mostly a symptom of scale and maturity cycles (which is one of the "good" problems to have in an opensource foundation), so let's work together to get there.

[srust]

As part of runtime, I will comment more specifically around that portion of the proposal.

TAG-Runtime has a very large scope today across many areas. I feel like this proposal is an improvement in that area, where the scope of what runtime covers appears to be reduced. There seems to also be some implied areas that fall under runtime, that are not listed but probably should be.

As proposed, the new scope is:

TAG Runtime

• Wasm
• Batch
• AI Compute
• Special Purpose Operating System

Additional areas of scope should also be these:

• core runtime
• kubernetes / distributions
• Serverless

I think it is also very important that we look at where specific projects would fall.

For runtime we feel these types of projects should still fall within runtime:

• kubernetes
• k3s
• k0s
• containerd
• crio
• youki
• knative
• keda
• wasmcloud
• kueue
• flatcar

It is unclear where some others fall such as spin / spinkube, kubeflow, etc, perhaps these are workload orchestration which has typically been runtime as well.

For the runtime working groups, I think it will be hard to split up a working group if those functions have now moved to be cross-TAG. The AI working group comes to mind - if there is a engaged community, splitting up that community I think would be likely to fragment it. So perhaps having some of the long-lived permanent working groups not be tied to a specific TAG, but still be able to operate independently is a good idea.

Beyond runtime, I do share some of the other comments around the differences between "app delivery" and "app development & workloads". Perhaps adding representative projects to each of the new TAGs as reference would help to be able to visualize what the changes mean in practice to specific projects.

The TAG Infrastructure now also feels like a big increasing scope bucket as well, like the former runtime, so should be careful not to make it too broad.

All that said, I appreciate all the effort and discussion gone into this, and looking forward to giving it a try.

In summary, my main feedback and takeaways:

• update runtime scope to include the additional areas above
• would be good to list representative projects falling in each new TAG scope, to help visualize impact, and better provide feedback
• splitting up working groups and communities is likely difficult

Thank you!

[craigbox]

Each project moving levels either requires, or may otherwise seek, (a) involvement from their domain-specific TAG (b) review from TAG Contributor Strategy and TAG Security.

TAG CS seems fine to me, in that it's 100% horizontal. TAG Security, however, has both a vertical (domain-specific) role for security products, plus it has a horizontal role assessing the security situation of all projects, no matter what their vertical TAG.

Has there been consideration to special-casing this responsibility, by splitting TAG Security into two groups, or otherwise ensuring that it has a larger staffing than other TAGs?

[raravena80]

It's great to see community members voice their concerns and suggestions — in my opinion, this is how progress happens.

Here's an idea: we could embrace a community-driven model. Rather than imposing a top-down structure, individual communities could organize themselves and present their proposals. Historically, the TOC established five TAGs (Security, Storage, Network, Runtime, and Observability, formerly SIGs) to spark interest and build momentum. However, as with all things in tech, evolution is inevitable.

By empowering each group to define its scope and foster collaboration with others, we can enable organic growth and innovation —much like how Contributor Strategy, Environmental Sustainability and the various Working Groups took shape.

My two cents.

Thanks!