cncf
[CNCF TOC] TAG Reboot: Restructuring Timeline
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
- [x] May 5: CNCF Blog announcing TAG Reboot and the nominations are open
- [x] May 5: Nominations open for new TAG Chairs (3 per TAG)
- [x] 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
- [x] 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
- [x] May 5: DRAFT TAG Charters and Subprojects
- [ ] #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
- [x] TBD: Create TAG and Subproject Slack Channels
- [x] TBD: Create TAG and Subproject Mailing Lists
- [x] TBD: Add owners to the Mailing Lists
- [x] TBD: Create document folder in the Projects drive per TAG and Subproject
- [x] TBD: Create agenda issue template for each group
- [x] TBD: Create Subproject GitHub issue template
- [x] TBD: Update README for tags.yaml
- [x] TBD: Create TAG YouTube Channels
- [x] TBD: New Logo artworks for TAGs
- [x] TBD: Update TOC Repo README
Migration
- [x] TBD: Clean up TAG Folder
- [x] TBD: Migrate Governance Review Assessments from TAG-CS Repo to TOC Repo
- [x] TBD: Move issues from TAG-CS Repo to TOC repo
- [x] TBD: Move Governance issue template from TAG-CS to TOC repo and block in TAG-CS
- [x] TBD: Add Nate to tags.yaml (Mentoring)
- [x] TBD: Change TAG-CS folder name
- [x] TBD: Move TAG Security reviews to TOC repo
- [ ] TBD: Move project reviews to TOC repo (longer task)
Landscape
- [ ] TBD: Update TAG Categorization in the landscape - landscape.yaml
- [ ] TBD: Update TAG Categorization in the landscape - mapping
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)?
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
Thanks @mnm678 !
- Please see this PR
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.
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.
Speaking from my experience with TAG Security, the problem hasn't been that people are being prevented from stepping up. The problem is getting people with the right skill set who have the time to spend. One of the reasons we have quite a few Tech Leads is that the needed skill set and commitment is more achievable. I think we've done a good job of encouraging people to step into this role whenever a good candidate has presented themself without feeling we need to turf out someone else who is also still active.
In comparison, we had a much harder time finding folks who could serve as TAG Chairs and are fortunate to have the ones we have now.
On Sun, May 4, 2025 at 5:37 PM Karena Angell @.***> wrote:
angellk left a comment (cncf/toc#1636) https://github.com/cncf/toc/issues/1636#issuecomment-2849451392
Thanks @mnm678 https://github.com/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.
— Reply to this email directly, view it on GitHub https://github.com/cncf/toc/issues/1636#issuecomment-2849451392, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGRODZTROKNY3FFL6RAUCL242CCLAVCNFSM6AAAAAB4B4XA46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBZGQ2TCMZZGI . You are receiving this because you are subscribed to this thread.Message ID: @.***>
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
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- There is reference to TAG policies that are essential to understanding enforcement mechanisms, but the definitions surrounding TAG policies are willingly omitted.
- 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.
- 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.
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 https://github.com/cncf/toc/pull/1647#discussion_r2070948941 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 https://github.com/cncf/toc/pull/1647#discussion_r2070804450 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 https://github.com/cncf/toc/pull/1647#discussion_r2070958581.
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 https://github.com/cncf/toc/pull/1647#discussion_r2070976167 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 https://github.com/cncf/toc/pull/1647#discussion_r2070937476 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.
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.
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/
I see "voting" mentioned in the docs and here - but is there a doc as to how voting will actually happen?
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
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 :)
https://civs1.civs.us/ is what we use for votes
cool! never seen that before! thanks!!
- TBD: Update TAG Categorization in the landscape - landscape.yaml
Should we do this update per TAG as the chart was merged and scope was defined?
@pacoxu the CNCF Projects team would work with the TOC to map projects to TAGs. Meta data would likely be added manually to the CNCF landscape to map projects to TAGs.
/cc @mrbobbytables
