search

cncf / toc

⚖️ The CNCF Technical Oversight Committee (TOC) is the technical governing body of the CNCF Foundation.
https://cncf.io
1.67k stars 632 forks source link

[Tracking] Implementation of an updated TAG formation process #1043

Open leonardpahlke opened 1 year ago

leonardpahlke commented 1 year ago

This is a follow up to this issue https://github.com/cncf/toc/issues/936 and proposes a structured approach implementing the problems mentioned. The goal of this issue is to coordinate the implementation.

Discussing the points mentioned in https://github.com/cncf/toc/issues/936...

  1. Organizational Introduction to TAGs and WG

To improve this, we can two sections to [tags/cncf-tags.md] (https://github.com/cncf/toc/blob/main/tags/cncf-tags.md) that discusses 1) the difference between TAGs, WGs, and the 2) process of creating a community group (project -> WG -> TAG), highlighting that not all projects warrant a WG and not every WG warrants a TAG.

Something like the diagram below could be useful. @amye I just drafted this up very quickly and I am sure its not 100% accurate (looking for support). 

---
title: Overview of the ToC, TAG and WG organizational structures
---
%%{init: {'theme':'neutral'}}%%
flowchart TB
    gov_board[CNCF Governing Board] <-.-> toc & cncf_staff
    cncf_staff[CNCF Staff] -.->|supporting| toc[ToC] & tag_security & tag_xyz
    toc -.->|extend in domains| tag_security[TAG Security] & tag_xyz[TAG XYZ]
    tag_security -.->|extend in domain areas| wg_sec_a[WG Security A] & wg_sec_b[WG Security B]
    tag_xyz -.->|extend in temporary action group| project_xyz_a[Project XYZ A]
    wg_sec_a -.->|extend in temporary action group| project_sec_a[Project Sec A]

    classDef dimensions fill:#ececff,stroke:#9572db,stroke-width:4px
    class dc,methodologies,infra,obs dimensions;
  1. TAG Template Repository

We could implement this by creating a template repository as suggested or by creating a folder within the toc repo with template files. The templates folder could be located in a subfolder of [toc/tags] (https://github.com/cncf/toc/tree/main/tags) which contains CODE-OF-CONDUCT.md, CONTRIBUTING.md and the files governance/*** (ref TAG ENV governance). I think a template folder in the toc repo is for simplicity, visibility and ownership reasons more desirable (opinions?)

  1. Roadmap for the creation of a TAG

To implement this we could create a new file toc/tags/cncf-tag-formation-process. There is a process but we might needs to discuss it again.

  1. Document lessons learned from other TAGs

We could add this as a section to the toc/tags/cncf-tag-formation-process file.

  1. TAG Bootstrap Mentor

I would see the ToC liaisons in this role, and can be picked up in the tag formation process (toc/tags/cncf-tag-formation-process). I think the support is especially important in the definition of the charter.

Additional comments

TAG Chairs onboarding

I remember @amye created an onboarding guide for TAG chairs. This might be something we could add as a markdown file as well?

Next steps

PTAL @TheFoxAtWork & @amye thanks!

cc @yimipeng

leonardpahlke commented 1 year ago

lanscape-overview-tags-toc I have also created this diagram a few weeks ago for Kubecon

TheFoxAtWork commented 1 year ago

First thank you for starting this! 1) @amye let's move the diagram over to the CNCF graphics team to pull together. Leo's initial outline looks like a good start but i know there are a lot more other areas. It would help bring clarity to the structure around the Foundation, particularly for new contributors, adopters, and members. 2) +1 to a template repository. Recommend engaging with TAG Contributor Strategy as they have a lot of templates already that could be reused effectively for TAGs. May be worthwhile to structure a charter template as well. 3) I love the idea of a roadmap, it gives us target points to check in with. My only recommendation is that it be outcome oriented and not timeline driven as some activities may move faster with community momentum and others may take longer. 4) Love the lessons learned - this gives us that historical knowledge of what transpired in the past, where we can do better, and potentially directly link to changes that came from that. 5) I like this in concept - i think the TOC liaison is responsible for this in some capacity (roles and responsibilities for that coming soon!) CC @nikhita . However it may be beneficial to also partner new chairs in a TAG or WG with other TAG or WG chairs and leads to ensure a well rounded support community.

Regarding onboarding for TAGs - yep this is still in draft. Amye has it on the TOC todo list.

joshgav commented 1 year ago

Thanks for starting this discussion @leonardpahlke!

Before we establish a process for forming TAGs (and WGs) let's review and ensure we share an understanding of their purpose! I believe TAGs should be delegates of and advisors to TOC with deep technical understanding of a domain of cloud-native computing. They should have the following objectives:

1) support individual projects in the TAG's domain throughout their lifecycle in meeting CNCF guidelines; share feedback with TOC 1) facilitate awareness and collaboration between projects in the TAG's domain; perhaps via WGs for related projects and subdomains 1) support end users in understanding and using projects in the TAG's domain; perhaps via whitepapers and samples 1) channel end user feedback to projects in the TAG's domain; perhaps via end user interviews and surveys

In TAG App Delivery at least we also have several subdomains as WGs, including GitOps, Platforms, Chaos Testing, and Artifacts. The TAG's job is partly to support and facilitate cooperation amongst these WGs and their projects. We create WGs for significant subdomains of application delivery (and development) with their own groups of projects and stakeholders.

For example per TAG App Delivery's model, perhaps a TAG for performance and optimization would be created with environmental optimization a WG within that TAG.

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 this issue to discuss this and rationalize several domain models CNCF has, like the Landscape, the list of TAGs and the list of platform capabilities.

leonardpahlke commented 1 year ago

@joshgav thanks for your input!

Before we establish a process for forming TAGs (and WGs) let's review and ensure we share an understanding of their purpose!

I agree 👍 thanks for sharing your insights.

I like your list and the points you raise. I think this can complement the introduction to TAGs and WGs very well. I would put this under the first implementation item 1. Organizational Introduction to TAGs and WGs and add it to the existing document tags/cncf-tags.md as I suggested earlier.

leonardpahlke commented 1 year ago

One question which arises is whether today's TAGs cover the full range of domains of cloud computing needed to support TOC?

Thats an interesting question, How to segment the cloud-native landscape into TAGs, and are there any blank spots?. This is certainly related to this discussion, but maybe it's worth creating a new issue for it?

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. I am sure this has been discussed before (cc @TheFoxAtWork, @dims).

TheFoxAtWork commented 1 year ago

The history of the TAGs (formerly SIGs) as I understand it to be, is they first started as groups of individuals with an interest in specific technology areas. Those working groups (TAG Security first started as the SAFE WG) coalesced like-minded individuals seeking to improve that technology or domain area. They initially defined their focus areas and deliverable types with guidance from the TOC (who provides oversight and alignment with the principles and charter). After some sustained momentum from those groups to execute on areas they defined, they were transitioned into SIGs, and eventually TAGs. These groups 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:

monadic commented 1 year ago

Hi that is not correct. I'm happy to explain but will do so a bit later.

TheFoxAtWork commented 1 year ago

Excellent thanks @monadic, your experience here would be immensely appreciated.

monadic commented 1 year ago

Hi folks

I shall try to be brief but I can definitely say more.

Our original vision was to create compelling momentum for cloud native projects like Kubernetes but not limited to its architecture. For example Prometheus and Envoy were never tied to containers. Indeed, nor is Kubernetes so much these days.

Thus we could get enough mindshare and backing that the tool chain would be unstoppable.

Part of the model, as implied above, was to avoid "one stack for all use cases" and other anti patterns like premature standardisation, optimisation, interop specification and the dreaded architecture diagrams. This upset many stakeholders who thought the purpose of the foundation was a commercial franchise for committees of vendors to commission a design and instruct legions of OSS community developers to implement. In addition to whatever the actual users wanted.

In other words "projects first". The governance was then meant to be an equal balance between small innovative vendors eg with VC backing, large slow established players, and end users who would act as the ultimate judges of product value.

Marketing would initially be easy if enough projects were "good" and more wanted to join.

However a story is needed and so as part of our mission, to deliver a complete set of leading tools for cloud native apps and infra, we created some content and diagrams. We knew as a TOC that if we did not do this, someone else would, and it would be wrong.

We made a "stack" diagram with a few layers and buckets to show roughly how things fit together, but without being too prescriptive (see above).

We filled this with logos to create a VC style landscape. I apologise for not keeping this inside the TOC. It used to be honest and helpful.

By the time we had done this people were asking when we woild 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.

LMK if more info needed.

Alexis

leonardpahlke commented 1 year ago

Thanks @monadic for the details on the story! Knowing about the history is important. I think this could be (summarized in a paragraph or two) a nice addition to the introduction to TAGs 1. Organizational Introduction to TAGs and WGs.

leonardpahlke commented 1 year ago

Thats an interesting question, How to segment the cloud-native landscape into TAGs, and are there any blank spots?. This is certainly related to this discussion, but maybe it's worth creating a new issue for it?

@TheFoxAtWork, @joshgav should we pursue this further? I would like to separate this from this issue, if possible, to keep this implementation in scope.

monadic commented 1 year ago

I should mention that tags (sigs) were deemed to be different from WGs. The former is intended to persist through time, while the latter has an end goal and exit strategy.

jberkus commented 1 year ago

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.

jberkus commented 1 year ago

Regardless, I think any TAG formation document needs to cover a few areas based on experience, that aren't mentioned in either issue. From my perspective, these are the three things every TAG needs :

  1. TAG needs staffing: any proposed new TAG should have a full complement of proposed officers, including at least three leads (e.g. two Chairs and a TL), and at least one proposed TOC liaison. At least one of the leads should be someone who has a track record of experience working in the CNCF. Proposed TAGs should also have a list of interested potential contributors.
  2. TAG needs projects: unless something is a "meta" TAG (like TAG-CS), 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.
  3. TAG needs charter: based on the above, the TAG should have a charter that clearly defines what its areas of responsibility are in a way that makes the TAG clearly distinct from other TAGs, as well as making it clear how that plugs into project matriculation and maintainer support.

Additionally, any TAGs which get formed by splitting of a major domain from existing TAGs need the blessing/support of the parent TAG in this (who would also need to revise their charter), and should have separate staffing from the older TAG. (Example: there's no point in having a Service Mesh TAG separate from TAG Networking, if it would have the same Chairs).

TheFoxAtWork commented 1 year ago
leonardpahlke commented 1 year ago

Thanks to everyone for their input! In the meantime, I've opened another issue to further discuss segmenting the CNCF landscape into TAGs, see https://github.com/cncf/toc/issues/1058.

I think we've gathered enough information for this issue to create some PR drafts. I will work on it - and let you all know here.

leonardpahlke commented 1 year ago

Regarding the second implementation item of this issue.

  1. TAG Template Repository

@ayme @RobertKielty, could we create a new GitHub template repository? Thanks! Maybe with the name template-tag or similar.

… @TheFoxAtWork gave a plus one in a comment above

+1 to a template repository

Recommend engaging with TAG Contributor Strategy as they have a lot of templates already that could be reused effectively for TAGs. May be worthwhile to structure a charter template as well.

^ I will reach out to TAG CS as soon as PRs are open!

leonardpahlke commented 1 year ago

could we create a new GitHub template repository?

Created a service desk ticket

TheFoxAtWork commented 1 year ago

@leonardpahlke thanks for following up here! Service Desk Ticket isn't quite the right path. I was digging into the template repo we have for projects and comparing with the kind of resources we have for projects on contribute.cncf.io. The templates are great but given that we have a lot of TAGs with varying degrees of awareness of the resources each of them have that allow for their operation and activity structures, a fully dedicated repo akin to cncf/project-template may not be best for our needs (we can always re-evaluate later) at the moment. If we established cncf/toc/tags/resources as the structure to host all the template files for TAGs, not limited to what is needed at time of creation, we could distinguish "core" files (governance, leadership structure, communications, etc.) and supporting files that allow the TAGs to conduct TOC supporting activities - I'm thinking through the upcoming exploration of project Annual Reviews and a guide on how to conduct a review. It provides TAGs a central place to get additional detail beyond the initial set up and allow TAGs to submit resources to assist each other that each of them feel maybe beneficial.

What do you think?

leonardpahlke commented 1 year ago

The templates are great but given that we have a lot of TAGs with varying degrees of awareness of the resources each of them have that allow for their operation and activity structures, a fully dedicated repo akin to cncf/project-template may not be best for our needs (we can always re-evaluate later) at the moment.

Sounds good 👍

If we established cncf/toc/tags/resources as the structure to host all the template files for TAGs, not limited to what is needed at time of creation, we could distinguish "core" files (governance, leadership structure, communications, etc.) and supporting files that allow the TAGs to conduct TOC supporting activities

Yes, I like it. I think this issue focuses mostly on the “core files” you mentioned. The “supporting files” would be a great addition, but we would need to collect first which kinds of activities we list here (review projects, more?, for me still somewhat unclear and in need of exploration). Maybe something we can pick up later in a new implementation issue?

Let me summarize the changes planned so far for this issue…

TheFoxAtWork commented 1 year ago

Looks good to me, let's get some other TAG Chairs to chime in?

Regarding those supporting files... yep definitely a later thing in a separate issue. You can stub it out as a folder structure with README to encourage TAGs to contribute those kinds of files to that folder and provide some ideas of what kind of things go in there. :). thank you again!

leonardpahlke commented 1 year ago

let's get some other TAG Chairs to chime in?

Yes! Any support is very welcome 🙏. If anyone wants to support, please open a draft PR as soon as you pick up one of these items (or comment here) so everyone knows, and we don't accidentally work on the same task.

Regarding those supporting files... yep definitely a later thing in a separate issue. You can stub it out as a folder structure with README to encourage TAGs to contribute those kinds of files to that folder and provide some ideas of what kind of things go in there.

Perfect 👍

nikhita commented 1 year ago

I really liked the WG chair proposal process that's called out for WG Green Reviews - https://github.com/cncf/tag-env-sustainability/pull/151 (specifically this doc).

Looks like something we should add to our TAG/WG resources 😄 cc @guidemetothemoon @leonardpahlke

leonardpahlke commented 1 year ago

Yes! It's quite similar to the TL process. I was hoping to merge the processes (Chair, TL, WG Chair) into one leadership-election-process

erinaboyd commented 11 months ago

@leonardpahlke thank you for pulling all this together. I think this in addition to feedback we hope to get from KubeCon Chicago around TAG leadership will be instrumental in making sure we have the right structure in place for TAG Chairs (roles, responsibilities, expectations) aligned with the TOC to enable us to scale out more effectively with the oversight and accountability expected by the community. Post KubeCon we will take the notes and feedback and work to get this closed out by the end of the year.

leonardpahlke commented 10 months ago

Just created this diagram to better explain the CNCF community structures to new TAG ENV contributors. Am I missing something in the diagram? We could add the diagram to the TOC repo. https://github.com/cncf/toc/blob/main/tags/cncf-tags.md TAG ENV CNCF Structure 2023-11-28-0005

leonardpahlke commented 5 months ago

We talked about this issue in the TOC meeting on April 16. Summary: