CNCF landscape segmentation into TAGs

[leonardpahlke]

Hello everyone, in a recent discussion around formalising the structures of TAGs (particular the formation process) a question about the segmentation of the CNCF landscape into TAGs came up. I think this is a very relevant topic since the CNCF landscape grows in size, new projects emerge which are between TAGs, the ToC has a lot on their shoulders (and the TAGs are their to support), new TAGs are getting proposed etc.

Do today's TAGs cover all areas of cloud computing required to support TOC?

This discussion is opened in a new issue to keep the discussion in #1043 in scope of the outlined implementation efforts.

Collection of comments about this topic in order, see 1043

@joshgav, link brings up the topic

One question which arises is whether today's TAGs cover the full range of domains of cloud computing needed to support TOC? I've opened https://github.com/cncf/tag-app-delivery/issues/398 to discuss this and rationalize several domain models CNCF has, like the Landscape, the list of TAGs and the list of platform capabilities.

@leonardpahlke, link

In a way, I see this pragmatically, because the community brings many proposals to form new groups when there is a growing interest, and it is up to the ToC and TAGs to support this. This is pretty much what happened for the TAG ENV. I would look at it from the bottom up rather than the top down. But depending on our common understanding, the segmentation is different and other TAGs and working groups make sense.

@TheFoxAtWork, link

[...] [TAGs] initially defined their focus areas and deliverable types with guidance from the TOC (who provides oversight and alignment with the principles and charter). [...] [TAGs] have always moved from the bottom up, establishing the interest first, defining the scope and needs, demonstrating capability, and then formalization if the work is capable of being sustained. Breaking this model would likely mean the creation of empty groups, with no momentum for completion of the work. Given that our projects and work are innovation, interest, and need-driven (much the same as the market), the creation of TAGs should mirror the same model as our projects for their creation and governance.

You could stretch the leveling framework to apply conceptually to the creation of TAGs:

sandbox==interest and initial ideas
incubation==working group with charter, aligned or partnered with an existing TAG
graduated==TAG, has demonstrated maturity in its execution, deliverables, and engagement with projects and other groups.

@monadic, link TAG history

[...] By the time we had [created the first CNCF landscape overview] people were asking when we would stop. How many projects, problems, layers? Other than wanting to rule out PaaS and hardware, we were unsure. We thought the market and users would figure this out. The TOC wasn't smart enough. And we were swamped. Backlogs were long. The community wanted to help. We tried a number of TOC Contributor ideas, sandboxes etc.

We needed to scale and create a community around the TOC to help handle the load. We needed more structure so that folks could help even if inexperienced. And we needed a way to set the perimeter of the CNCF. The idea then was to create 5-7 subgroups or "categories" around each main active bucket on the CNCF TOC stack and landscape (OG version not the monster).

This became SIGs because we could explain it by saying "like Kubernetes but for all the projects". And like the k8s groups anyone could join not just paid sponsor reps. We asked for support for this at a GB TOC meeting, in SF, a year or so before the pandemic. Everyone loved the idea and wanted more education, white papers, use case patterns, projects.

We were all very surprised when LF launched CD foundation to compete with cncf app delivery sig. It took a while to get the right balance of power to launch it. As with all TOC we knew we needed to iterate. My last act as chair was to get the SIGs up and running. Liz's TOC changed them from SIGs to TAGs... as reasoned in the community audit logs. I think the concept continues to evolve.

@jberkus, link

One of the problems we already observed with WGs is that they need to report to another group, otherwise it becomes unclear how to meet their goals. That was the reason for the current policy that WGs are under a TAG. There are lots of reasons why you might want a WG that reports directly to the TOC, but the current reality is that the TOC doesn't have the spoons to supervise WGs.

The structure further morphed when certain TAGs (including Contrib-Strat, AppDelivery, and Networking) discovered a need to have standing subcommittees to deal with very focused efforts. In the absence of some other structure, these subcommitees got called Working Groups. They have no expected termination conditions, other than destaffing. So the idea that WGs are time-limited (which we borrowed from Kubernetes) is no longer applied.

@TheFoxAtWork, link

Regarding [CNCF Landscape Segementation into TAGs], let's track this separately. We've got a lot of labeling concepts and restructuring in planning to bring more alignment around this.

• With the additional discussion here, we have some practice in how this has worked in the past which i believe can be firmed up to address this after we've got this captured and the additional changes forthcoming. @jberkus 's comment in particular is meaningful here:

• there is no reason to propose a TAG for projects that do not yet exist or are not planning to join the CNCF. For any future "meta" tags, they should be addressing specific areas of pre-existing in-CNCF activity.

• For topic and domain areas where projects don't yet exist, but we are beginning to feel and experience a shift (LLM, AI, ML, as examples) and potentially see the integration or creation of projects coming in those areas, these would be exploratory in a working group function aligned with an existing TAG until enough momentum and need is reached to warrant the commitment a TAG provides those domain and "meta" areas.

Regarding TAGs/SIGs/WG - @jberkus comments certainly resonate with what I've experienced (here and in other foundations). We as a community may develop focused groups that may or may not be time/delivery bound (regardless if we call them Working Group or something else that articulates their longevity). There are occasions and needs for both to exist within our community.

Goals of this discussion

• Further discuss this topic
• Firm up our common idea of TAGs (and their scope)
• Firm up the process (ref comment)

Proposed open discussion items

How does segmenting the CNCF landscape into TAGs...

• ... help the ToC (TAG goal support the ToC) -> does it even make a significant different?
• ... help CNCF projects (TAG goal engaging with projects) -> are the TAGs granular enough? or there areas in the landscape which can be supported by other LF foundations (leveraging other foundations more actively)
• ... help the community to innovate -> does the segmentation influence the innovation of new/existing projects
• ... change the way we collaborate across projects
• ... how does this help end users navigating the landscape
• ... how does this help figuring out which projects to use

[caniszczyk]

I think we can easily do this in the landscape today without much work

For example, each landscape entry, especially projects have an "extra" field for new attributes

e.g., https://github.com/cncf/landscape/blob/master/landscape.yml#L2623

This would allow you to filter by all projects that are self identified as specs:
https://landscape.cncf.io/card-mode?specification=true

We could add an extra attribute for "tag: cncf-tag-security" etc

And simply add this as part of the onboarding process of a project and also have TAGs manage things.

We could also add the info to the card in a project or make a small UI enhancement.

In short, I think this is a GOOD IDEA and won't be too much work to implement something that can be used quickly.

[leonardpahlke]

Thats a good call out! Would be great to add this info!

This issue focused more on the question "Do today's TAGs cover all areas of cloud computing required to support TOC?" -> "How do we think about segmenting the CNCF landscape into TAGs?". I have updated the issue description slightly.

[raravena80]

FYI, folks within TAG-Runtime have also come forward about the need to have a place to display the projects that are within the scope of the TAG and its working groups.

cc: @stackedsax

[lizrice]

This seems like a good suggestion, in that it should be easier for people to find the appropriate TAG for discussing a particular project (or alternatives to that project)

The list of open discussion items in the OP might also include: how does this help end users navigating the landscape and figuring out which projects to use? To which one answer might be, it will be easier to find the TAG for a given project, which might lead them to useful TAG resources e.g. white papers.

[leonardpahlke]

Thanks for the input @lizrice - I've added the two items under the "Discussion" section ✅.

[amye]

This work is also being tracked here: cncf/landscape#2834

[TheFoxAtWork]

In the new landscape we'll have the ability to see the projects associated with TAGs. This isnt yet done.

[jeefy]

Landscape YAML is updated to have TAG metadata! :)