8000 [CNCF TOC] TAG Reboot: Restructuring Timeline · Issue #1636 · cncf/toc · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[CNCF TOC] TAG Reboot: Restructuring Timeline #1636

8000
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
22 of 42 tasks
angellk opened this issue Apr 29, 2025 · 14 comments
Open
22 of 42 tasks

[CNCF TOC] TAG Reboot: Restructuring Timeline #1636

angellk opened this issue Apr 29, 2025 · 14 comments
Assignees
@angellk @mrbobbytables @riaankleinhans
Milestone
Q2 2025

Comments

@angellk
Copy link
Contributor
angellk commented Apr 29, 2025 •
edited
Loading

This tracking issue provides the timeline for the Restructuring. As external factors have shifted CNCF project team resources temporarily, all dates are subject to change - though the TOC and CNCF Project team will attempt to adhere to closely.

Elections for New TAG Chairs

  • May 5: CNCF Blog announcing TAG Reboot and the nominations are open
  • May 5: Nominations open for new TAG Chairs (3 per TAG)
  • May 19: Nominations close for new TAG Chairs
  • May 19-21: Qualification period for new TAG Chairs
  • May 21: TOC Vote opens for new TAG Chairs via CIVS for TOC Members only
  • June 2: TOC Vote closes for new TAG Chairs
  • June 2: Newly seated TAG Chairs announced

Elections for New TAG Technical Leads

  • May 5: Nominations open for new TAG Technical Leads
  • May 19-21: Qualification period for new TAG Technical Leads
  • May 19: TOC Vote opens for initial TAG Technical Leads (3 per TAG) via CIVS for TOC Members only
  • June 2: TOC Vote closes for initial TAG Technical Leads
  • June 2: Initial round of newly seated TAG Technical Leads announced
  • July 7: Nominations close for new TAG Technical Leads
  • July 7: TOC and TAG Chairs Vote opens for new TAG Technical Leads (TAG Chairs only vote for their TAG TLs)
  • July 28: TOC and TAG Chairs Vote closes
  • July 28: Newly seated Technical Leads announced

TAG Documents and Tools

  • May 5: DRAFT TAG Charters and Subprojects
  • Archival of previous TAG and WG slack channels #1666
  • June 24: Archive previous TAG and WG slack channels
  • July 7: Final Charters due for TOC vote
  • July 7: TOC Review and Vote opens for TAG Charters
  • July 28: TAG Charters finalized
  • TBD: Create TAG and Subproject Slack Channels
  • TBD: Create TAG and Subproject Mailing Lists
  • TBD: Add owners to the Mailing Lists
  • TBD: Create document folder in the Projects drive per TAG and Subproject
  • TBD: Create agenda issue template for each group
  • TBD: Create Subproject GitHub issue template
  • TBD: Update README for tags.yaml
  • TBD: Create TAG YouTube Channels
  • TBD: New Logo artworks for TAGs
  • TBD: Update TOC Repo README

Migration

Landscape

  • TBD: Update TAG Categorization in the landscape - landscape.yaml
  • TBD: Update TAG Categorization in the landscape - mapping
@angellk angellk added this to the Q2 2025 milestone Apr 29, 2025
@mnm678
Copy link
Contributor
mnm678 commented Apr 30, 2025

Thanks for this timeline! I have a few questions to clarify the election before it gets going. Let me know if there’s documentation on this somewhere that I missed.

  • Is there documentation that summarizes responsibilities for chairs and TLs?
  • Do all TLs need to take on all responsibilities, or is there flexibility to utilize the expertise and availability of each TL?
  • How long are terms for chairs and TLs? Will there be term overlap for new chairs/TLs? Who will rotate out of the roles first?
  • How many total TLs will there be for each TAG (it looks like 3 in the first round, but how many in the second)?

@angellk
Copy link
Contributor Author
angellk commented May 2, 2025

Thanks @mnm678 !

  • Please see this PR
  • It would be good to understand which responsibilities seem excessive
  • Terms are 2 years except for the initial seating will have 1 year terms too - in the nomination, please specify whether you, or other community members, prefer the 1 year or 2 year term
  • For the second round, 2 additional Technical Leads for a total of 5 per TAG, if the TAG requires more -- an exception can be requested, reviewed and voted on by the TOC

@mnm678
Copy link
Contributor
mnm678 commented May 2, 2025

Thanks @mnm678 !

Thanks!

  • It would be good to understand which responsibilities seem excessive

For folks who do this work outside of their day job, the 10-20% of your working hours requirement is not feasible.

@angellk
Copy link
Contributor Author
angellk commented May 4, 2025

Thanks @mnm678

For folks who do this work outside of their day job, the 10-20% of your working hours requirement is not feasible.

We have many community members who are overextended. This is a great opportunity for introspection across the board.

  • If a community member is serving in multiple leadership areas -- is this the time to allow for other community members to step in?
  • If a community member doesn't have the time to commit, this is also the opportunity to engage with the TAGs and Subprojects in a way that doesn't require consistent time commitment.

The TOC would like to emphasize that it's okay to be emeritus as well as not hold a title. There are still ways to engage with and contribute to the community.

@JustinCappos
Copy link
Contributor
JustinCappos commented May 4, 2025 via email

@eddie-knight
Copy link
Contributor
eddie-knight commented May 4, 2025 •
edited
Loading

I've mostly been waiting to see the finalized policy changes to form an opinion, and a few of my questions were answered on the PR before it was merged. Thanks for that.

But as the Co-chair of TAG Security, I do wish there was more opportunity to tangibly collaborate on the policy.

Because this governance change moves a high degree of authority to the TOC while putting an even higher degree of responsibility on the TAG and its leaders, the new policy needs to be bulletproof.

And because the community needs to have the most capable, available, and motivated folks leading TAGs, this level of control being asserted by the TOC needs to be done in a way that creates confidence and clarity without any mystery.

Hidden for brevity: some items I'll be working on PRs for
  1. As written, the requirements place a significant amount of responsibility on TAGs to provide constant project oversight.
    • Combined with the time-based obligations, this is a massive divergence from the historic role of TAGs as advisory groups that voluntarily respond to requests rather than oversight bodies that are responsible for going out to gather information.
    • This is a situation where there is great responsibility with little power — a recipe for discontent over time
  2. The document places a requirement that the TOC can only approve TAG leaders with experience in the CNCF community, but then — in the same breath — carves out an exception allowing the TOC to disregard this requirement at it's own volition.
    • I assume this isn't malicious, but it leaves the door open for unintended consequences and concerns that the TOC can fill TAG leadership with reps from the biggest logos. Even if it's not an intent right now, this phrasing gives the TOC that power any time in the future.
  3. The scope of a TAG is not concrete, and its definition does not belong to the TAG — with many implicit and at least one explicit statement of such.
    • This means that the responsibility a leader accepts will change due to factors outside of their own control, both in spikes and potentially in a steady increase over time as the TOC moves more groups into the TAG. We had this happen once to TAG Security and it was not a painless process for TAG leadership.
  4. The document was not updated to restrict the personas that can act as a replacement for appointed roles.
    • As written, a TAG chair could hand off their role to a colleague from their firm who has no context to successfully lead the community or operate within the CNCF context.
    • Also, there is no process prevent a temporary replacement from holding the role permanently in the event that the replaced person does not return.
  5. The duties as they are written need to be sorted into responsibilities of the group, its parents group, and duties of the individual holding the role.
    • Failure to fix this will prevent any complete understanding of expectations and thus accountability. This is true throughout the document, and in some places more than others.
  6. Many unknown obligations are present, which result in reputational risk that must be tolerated (especially by chairs):
    • Some key definitions have been left intentionally undefined. (1, 2)
    • Some requirements have room for interpretation
    • The frequency of mandatory TAG status updates to the TOC is left intentionally vague, resulting in an unknown obligation for both chairs and tech leads.
    • The frequency and form of TAG charter progress updates is left intentionally vague, same problem as above.
  7. The mechanism for evaluating progress in peer-held roles is left intentionally vague, resulting in a toleration of absence but an unquantifiable threshold for accountability.
    • The list of what's being measured doesn't need to be included, but the mechanism should be.
  8. There is reference to TAG policies that are essential to understanding enforcement mechanisms, but the definitions surrounding TAG policies are willingly omitted.
  9. The meaning of "parent governing body" is used with low-fidelity throughout the document, in spite of it being an impactful term everywhere that it is used.
  10. I'm told that metadata has a standardized location, but I still haven't found it. If the implementation is part of the requirement, it should be documented alongside the requirement to avoid accidental divergence.

@mrbobbytables
Copy link
Member
mrbobbytables commented May 5, 2025 •
edited
Loading

Responding via comment, just know that there IS still some vagueness because we don't know yet for some of these things. We need something that strikes a good balance and that'll come as we move forward.

As written, the requirements place a significant amount of responsibility on TAGs to provide constant project oversight

How does SHOULD check in with incubating and graduated projects mean constant oversight? What we're looking for is for communication with projects, the initiatives and subprojects are meant to be more project focused. With the community meeting ramping up, and everything being designed around more communication with projects - getting a general idea of trends across them should be easier.

The document places a requirement that the TOC can only approve TAG leaders with experience in the CNCF community, but then — in the same breath — carves out an exception allowing the TOC to disregard this requirement at it's own volition.

Because people SHOULD come from the CNCF community, but there are potential exceptions to this when a new domain is spinning up or the need is great. A good example is the majority of new TAG Security TLs had -0- (documented) experience within CNCF spaces.

I assume this isn't malicious, but it leaves the door open for unintended consequences and concerns that the TOC can fill TAG leadership with reps from the biggest logos. Even if it's not an intent right now, this phrasing gives the TOC that power any time in the future.

It relies on the TOC being a body made up of many different groups with different representation. It'd awfully be hard for the TOC to put a vendor in place with alignment to get a full vote.

The scope of a TAG is not concrete, and its definition does not belong to the TAG — with many implicit and at least one #1647 (comment) of such.
This means that the responsibility a leader accepts will change due to factors outside of their own control, both in spikes and potentially in a steady increase over time as the TOC moves more groups into the TAG. We had this happen once to TAG Security and it was not a painless process for TAG leadership.

Regarding the referenced comment, the TOC and TAGs have to opt-in to what initiatives they take on, and just their own bandwidth to what is achievable. If they want to do them, but don't have bandwidth - they can sit in the backlog. Remember that they are meant to be lightweight with minimal oversight. The TL just needs to keep a pulse check on them to see how they're going and if they're still making progress. If they aren't, then they go back to the backlog until there are resources to take them on.

As written, a TAG chair could hand off their role to a colleague from their firm who has no context to successfully lead the community or operate within the CNCF context.

All responsibilities that are handed off require a charter update, the charter update is the mechanism that keeps this in check because the TOC has to approve charters.

The duties as they are written need to be sorted into responsibilities of the group, its parents group, and duties of the individual holding the role.
Failure to fix this will prevent any complete understanding of expectations and thus accountability. This is true throughout the document, and in #1647 (comment) more than others.

That specific comment regarding TLs - the scope is for the TLs of the TAG. It's a shared responsibility across them. The TAG has its own general responsibilities they need to cover (outlined in the TAG portion above the roles). The duties are then split across the chairs and TLs.

Many unknown obligations are present, which result in reputational risk that must be tolerated (especially by chairs)

Things like reporting are TBD because we don't know yet what reporting frequency should look like yet. We need to find something that is reasonable, but we don't explicitly know it yet. It's not like its going to be a daily check-in.

The mechanism for evaluating progress in peer-held roles is left intentionally vague, resulting in a toleration of absence but an unquantifiable threshold for accountability.

Those should be covered be the leadership principles (as they were before)

There is reference to TAG policies that are essential to understanding enforcement mechanisms, but the definitions surrounding TAG policies are #1647 (comment).

TAG policies require charter changes which in turn require TOC approval. It's intentionally vague to account for different situations for each TAG.

The meaning of "parent governing body" is used with #1647 (comment) throughout the document, in spite of it being an impactful term everywhere that it is used.

It can be updated in the TAG Chair and TL roles, but for subprojects and initiatives it's that way because they could be TOC or TAG level items, in which case its either up to the TAG or TOC as the parent body.

I'm told that #1647 (comment) has a standardized location, but I still haven't found it.

It's at the root of the TOC dir - https://github.com/cncf/toc/blob/main/tags.yaml

when that file is touched, a bot will open a PR and run the generator that uses templates and renders them out in the appropriate locations.

@eddie-knight
Copy link
Contributor

Thanks @mrbobbytables and @angellk for working through to help us understand some of the intent behind certain phrases and approaches. Where possible, I'll open up PRs to address the most salient points above.

This was referenced May 5, 2025
Merged
Open
Open
Open
Open
Open
Open
Open
Open
Open
Open
@angellk
Copy link
Contributor Author
angellk commented May 7, 2025

Initial Announcement blog posted (series of blogs to follow):
https://www.cncf.io/blog/2025/05/07/10-years-in-cloud-native-toc-restructures-technical-groups/

@eddie-knight eddie-knight mentioned this issue May 14, 2025
Open
15 tasks
@sunstonesecure-robert
Copy link

I see "voting" mentioned in the docs and here - but is there a doc as to how voting will actually happen?

@mfahlandt
Copy link

I see "voting" mentioned in the docs and here - but is there a doc as to how voting will actually happen?

It's stated in the Todo list - TOC will vote

@sunstonesecure-robert
Copy link

I see "voting" mentioned in the docs and here - but is there a doc as to how voting will actually happen?

It's stated in the Todo list - TOC will vote

Vote how? in an open forum? in GitHub? by paper ballots in Rome with white smoke :)

@dims
Copy link
Member
dims commented May 20, 2025

https://civs1.civs.us/ is what we use for votes

@sunstonesecure-robert
Copy link

https://civs1.civs.us/ is what we use for votes

cool! never seen that before! thanks!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@angellk angellk

@mrbobbytables mrbobbytables

@riaankleinhans riaankleinhans

Labels
None yet
Projects
CNCF TOC Board
Status: New
Milestone
Q2 2025
Development

No branches or pull requests
9 participants
@dims @angellk @JustinCappos @mfahlandt @mrbobbytables @mnm678 @eddie-knight @riaankleinhans @sunstonesecure-robert
0