Governance proposal for public review: Steering Committee and Technical Committee drafts

[John15321]

This discussion is a continuation of the governance conversation I started on the Flatcar maintainers mailing list.

As part of our ongoing evolution as a CNCF project, and in preparation for CNCF Graduation, we need to formalize parts of our governance. The current proposal is to introduce:

• Steering Committee for non-technical governance matters
• Technical Committee for cross-cutting technical direction and escalation

I am opening this discussion publicly so the wider Flatcar community can review the draft, comment on it, and help shape it before we move to a formal vote.

Please review the draft here:

Google Doc draft: https://docs.google.com/document/d/1dc_vHWNGH4XXqqqVS_seeS_Yv2A4P0qcKs3WMf5g1Hs/edit?usp=sharing

Governance discussion questions:
https://docs.google.com/document/d/1EzZIdoe4fJYCj8GuWyot-WdQVu6BubqB_pS0qmeQ2A4/edit?pli=1&tab=t.0

Anyone with the link can view the document.

For maintainers: I will send individual email invites for commenting and editing access. If you add feedback directly in the document, please either:

• use the Google Docs comment feature, or
• add text in a different color

so that suggested changes are easy to spot and discuss.

What the current draft is

This is intentionally still a draft.

Where you see X in the document, that means the point is still open for discussion and has not been decided yet.

Examples of open items include:

• number of seats on each committee
• whether there should be different seat types
• how contributor and community representation should work
• who can run and who can vote
• term length and term limits
• same-company representation rules
• election method
• voting thresholds
• meeting cadence
• quorum and amendment process

The goal is to make the unresolved governance choices easy to spot and easy to discuss before we finalize anything.

Why this is public now

This is the public continuation of the email thread on the maintainers channel.

The maintainers will ultimately vote on the governance changes by email later, but before that happens I want the proposal and the discussion around it to be visible and reviewable in public.

That way:

• maintainers can discuss the proposal in the open
• community members and heavy users of Flatcar can react to it
• we can improve the proposal before anyone has to vote on the final version

Discussion meetings before voting

Before the formal vote, we will hold two live discussion meetings:

• Thursday, July 9, 2026
• Tuesday July 14, 2026
• Thursday, July 16, 2026

These two dates were chosen because they ended up tied in the availability poll, so rather than forcing a choice between them, we will use both.

These meetings are for discussion and refinement of the proposal. The actual vote will happen later by email.

To choose times for the two meetings, I prepared Doodle polls with hour-by-hour slots so people can mark when they are available and when they are not.

For security reasons, I will share the Doodle links only in the internal maintainers Discord channel and in the existing maintainer email thread, not here in the public Discussion.

Also, a small logistical note: I had to use multiple Doodle accounts to work around the premium subscription limits while setting these up.

We will use Jitsi for both meetings:

• Meeting link for July 9: https://meet.flatcar.org/Discussions
• Meeting link for July 14: https://meet.flatcar.org/Discussions
• Meeting link for July 16: https://meet.flatcar.org/Discussions

If we record the meetings, I will also add the recording links here afterward:

• Recording for July 9: Part 1 Part 2
• Recording for July 14: [ADD RECORDING LINK HERE]
• Recording for July 16: [ADD RECORDING LINK HERE]

Async participation

If you cannot attend live, please still review the draft and leave feedback here.

You are also welcome to share comments asynchronously through the usual maintainer communication channels. The point of these meetings is to stress-test the proposal and improve it before the formal vote, not to make attendance the only way to participate.

Join us on Discord to review:

• Friday, July 10: 11:30AM UTC Discord Link
• Monday, July 13: 11:30AM UTC
• Wednesday, July 15: 11:30AM UTC

Google Doc draft
Governance discussion questions

What I am asking for

Please review the draft and comment on:

1. whether this Steering Committee + Technical Committee structure makes sense for Flatcar
2. which responsibilities should belong to each committee
3. which responsibilities should explicitly stay with maintainers and subgroups
4. the open X items in the draft
5. any major concerns, missing pieces, or better alternatives

I will post the numbered discussion questions in a comment below so they are easy to reference.

[John15321]

As promised, here is the numbered list of discussion questions for the draft.

A quick note on the document: whenever you see X, that means the point is intentionally still open and needs discussion before we finalize anything.

For reference, some of these questions are informed by how other CNCF projects structure governance:

• Kubernetes uses a 7-member Steering Committee, 2-year staggered terms, and a one-third same-company cap.
• Istio uses both a Steering Committee and a Technical Oversight Committee. Its Steering Committee includes Contribution Seats and Community Seats, and uses 1-year terms.

Governance discussion questions

Moved to: https://docs.google.com/document/d/1EzZIdoe4fJYCj8GuWyot-WdQVu6BubqB_pS0qmeQ2A4/edit?usp=sharing

Details

A. Overall structure

1. Should Flatcar have both a Steering Committee and a Technical Committee?
What problem are we trying to solve by creating two committees instead of continuing with the current maintainer-led model?

2. What should the Steering Committee be responsible for?
Should it focus strictly on non-technical matters such as governance, branding, CNCF relations, and project-wide assets?

3. What should the Technical Committee be responsible for?
Should it handle cross-cutting technical direction, architecture, and escalations, while leaving normal engineering decisions to maintainers and subgroups?

4. What work should explicitly remain outside both committees?
For example, should normal repo creation, CI setup, access management, package additions, issue triage, and routine PR review stay with the usual maintainer and subgroup flow without committee approval?

5. How should the two committees work together?
Should they meet jointly on a regular basis, only when needed, or not at all unless a matter overlaps both areas?

B. Steering Committee design

6. How many seats should the Steering Committee have?
Kubernetes uses 7 elected Steering seats. Istio uses 13 Steering seats split across different seat types. What size makes sense for Flatcar?

7. Should the Steering Committee have one type of seat or multiple seat types?
Kubernetes uses one class of elected member. Istio splits Steering into Contribution Seats and Community Seats. Should Flatcar distinguish between those kinds of representation?

8. If there are multiple Steering seat types, how many seats should belong to each type?
For example, how many contributor seats and how many community seats should there be?

9. Who should be eligible to run for the Steering Committee?
Should this be limited to current maintainers, expanded to emeritus maintainers, or opened to a broader contributor or community group?

10. Who should be eligible to vote in Steering Committee elections?
Should voting be limited to maintainers, opened to contributors, or opened more broadly to community members?

11. How should non-code contributions be recognized in Steering voter eligibility?
Istio explicitly allows voting exceptions for meaningful non-code contributors. Should Flatcar do something similar?

12. How long should a Steering Committee term be?
Kubernetes uses 2-year terms. Istio uses 1-year terms. What would work best for Flatcar?

13. Should Steering Committee terms be staggered or should all seats turn over at once?
Kubernetes staggers terms. Istio reseats the whole Steering Committee together each year.

14. Should there be term limits for the Steering Committee?
If yes, should the limit be based on number of consecutive terms, total consecutive years, or something else?

15. If there are term limits, should there be a required break before someone can serve again?
If yes, how long should that cooling-off period be?

16. Should there be a same-company representation limit on the Steering Committee?
Kubernetes limits Steering to one third from any one company. Istio uses a broader cap with additional seat-type rules. Should Flatcar adopt something similar?

17. If Flatcar adopts a same-company limit, how should it work in practice?
How should the project handle election results or mid-term employer changes that would break the rule?

18. How should Steering Committee vacancies be filled?
Should the seat go to the next runner-up, be filled by appointment, require a special election, or stay open until the next cycle?

19. How should a Steering Committee member be removed if necessary?
What threshold and process should apply for removal?

20. Should Flatcar recognize former Steering Committee members as Emeritus?
If yes, should that status be honorary only, or come with some advisory role?

21. What voting threshold should the Steering Committee use for normal decisions?
Kubernetes uses a majority for routine business. Istio uses 60 percent. What should Flatcar do?

22. What voting threshold should apply to Steering charter changes?
Istio uses 80 percent for charter changes. Should Flatcar use a higher threshold for foundational changes too?

23. What meeting cadence should the Steering Committee have?
Should it meet weekly, monthly, quarterly, or only as needed?

24. Should Steering Committee meetings be open, closed, or mixed?
Kubernetes uses both open and closed meetings. Istio Steering meetings are not currently public. What is the right default for Flatcar?

25. What quorum should apply for Steering meetings and votes?
Should there be one quorum for holding a meeting and another threshold for taking a vote?

C. Technical Committee design

26. How many seats should the Technical Committee have?
Istio's TOC has 6 seats. What size makes sense for Flatcar's technical body?

27. Who should be eligible to run for the Technical Committee?
Should eligibility be limited to current maintainers, or should it include emeritus maintainers or other trusted technical contributors?

28. How should Technical Committee members be selected?
Should they be elected, appointed, nominated and approved, or chosen some other way?

29. Who should be eligible to choose or vote for Technical Committee members?
Should this be all maintainers, the Steering Committee, the existing Technical Committee, or some broader technical electorate?

30. How long should a Technical Committee term be?
Istio's TOC uses 2-year staggered terms. Should Flatcar use the same or something shorter?

31. Should Technical Committee terms be staggered or all turn over together?
Would staggering help preserve technical continuity?

32. Should there be term limits for the Technical Committee?
If yes, should they match the Steering Committee limits or be different?

33. If there are term limits, should there be a required break before someone can return to the Technical Committee?
If yes, how long?

34. Should there be a same-company representation limit on the Technical Committee?
Should it match the Steering Committee rule, or should the technical body have a different standard?

35. How should Technical Committee vacancies be filled?
Should there be a by-election, appointment, runner-up replacement, or another mechanism?

36. How should a Technical Committee member be removed if necessary?
Who should have that authority, and what threshold should apply?

37. Should Flatcar recognize former Technical Committee members as Emeritus?
If yes, should emeritus status be honorary only or come with some continuing role?

38. Should the Technical Committee work primarily by consensus, or use defined voting thresholds more regularly?
Istio explicitly says its TOC should operate by consensus. Should Flatcar do the same?

39. What voting threshold should apply when the Technical Committee does need to make a decision?
Should routine decisions and major architectural decisions use different thresholds?

40. What meeting cadence should the Technical Committee have?
Should it meet regularly, and if so how often?

41. Should Technical Committee meetings be open, closed, or mixed?
Istio's TOC meetings are open to observers. Should Flatcar follow that model?

42. What quorum should apply for Technical Committee meetings and votes?
Should there be explicit quorum rules here too?

D. Steering election model

43. Should Flatcar use a single election model for Steering, or a mixed seat model?
Kubernetes uses a single elected Steering body. Istio splits seats between Contribution Seats and Community Seats. Which model fits Flatcar better?

44. If Flatcar uses contribution-based seats, how should contribution be measured?
Should this rely on GitHub activity, review activity, issue triage, release work, docs work, or some broader formula?

45. If Flatcar uses community seats, who should be eligible to run for them?
Should companies that already hold contributor seats be excluded from community seats, as in Istio?

46. What voting method should Flatcar use for Steering elections?
Kubernetes and Istio both use Condorcet in major governance elections. Should Flatcar also use Condorcet, or something simpler?

47. If Flatcar adopts a same-company rule, how should that rule affect election results?
Should lower-ranked candidates from an over-represented company be dropped, as Kubernetes does?

48. Who should run Steering elections?
Should elections be run by election officers, the current committee, or some other neutral group?

49. How long should the Steering nomination period and voting period be?
Should these be defined precisely in the governance documents?

50. How should Steering election results be published?
Should Flatcar publish only the winners, or also ranked results, vote totals, seat allocation details, or more?

51. Should there be formal rules about campaigning, recusal, and election administration?
Kubernetes and Istio both treat election administration as a real governance function. How much structure does Flatcar want here?

E. Amendment and governance process

52. Who should have the final authority to approve committee charters and charter changes?
Should that be the maintainers as a whole, the Steering Committee, the Technical Committee, or some combination?

53. What process should be used to propose and adopt charter changes?
Should changes require a pull request, mailing-list or public notice, discussion period, vote, and waiting period?

54. Should the process for changing the governance model itself be harder than normal committee decisions?
If yes, how much harder should it be?

[John15321]

9th, 14th and 16th of July

Open office-hours session to discuss and refine the Flatcar governance draft introducing a Steering Committee and a Technical Committee.

This meeting is for live discussion, feedback, and proposal improvement before any formal maintainer vote.
No final vote will be taken during this session.

Topics may include:

• committee scope and responsibilities
• election/selection model
• term length, limits, and vacancies
• representation and same-company limits
• voting thresholds, quorum, and amendment process

Everyone reviewing the draft is welcome to participate.
If you can’t attend live, please provide async feedback in the GitHub discussion thread.

Meeting link: https://meet.flatcar.org/Discussions
Recordings: If recorded, links will be posted in the GitHub discussion thread afterward.
All meeting recordings, notes documents, and written discussion records will be collected and kept up to date in this thread: #2202

[John15321]

https://github.com/istio/community/blob/master/ROLES.md
https://github.com/kubernetes/steering/blob/main/elections.md#maximal-representation

[John15321]

@LexiNadolski : Maybe renaming Escalations to something like "Mediation" to avoid connotations with negative feelings/conflicts etc - or something else

[John15321]

👋 Hi everyone!

A huge thank you to everyone who attended today's discussion meeting regarding the proposed Steering and Technical Committees. It was fantastic to see so much engagement as we formalize our governance for CNCF graduation! 🚀

🎥 Meeting Recordings
If you couldn't make it live or want to review the conversation, the recordings are now up on YouTube:

• Part 1
• Part 2 (Note: We experienced a minor technical hiccup that interrupted the stream for about 10 minutes, but it picks right back up! 😅)

📝 Join the Discussion (Your Input is Needed!)
We have created a dedicated document to track and discuss all the open governance questions that were brought up.

• Discussion Questions Document
• Original Governance Draft

Whether you are a maintainer or a community member, your voice matters. 🗣️ Please jump into the documents and leave your comments, opinions, and questions. You can also join the broader conversation on our GitHub Discussions thread (#2202).

📅 Upcoming Meetings Schedule
We have several more opportunities lined up to continue refining this proposal together. Feel free to drop in!

• ☕ Friday, July 10 @ 13:30 CET: Casual Governance Hangout — A slow-paced, casual chat about the governance work.
• ☕ Monday, July 13: Casual Governance Hangout
• 🏛️ Tuesday, July 14 @ 14:00 - 17:00 CET: Semi-Official Discussion Meeting (Meeting Room)
• ☕ Wednesday, July 15: Casual Governance Hangout
• 🏛️ Thursday, July 16 @ 14:00 - 17:00 CET: Final Semi-Official Discussion Meeting (Meeting Room)

Looking forward to seeing you at the next sessions! 🙌

[John15321]

Huge thanks to everyone who joined us to talk about the new proposal over the last week. By the end of this week we will send you a draft that will take into account all of your feedback both verbal and written! Stay tuned! :)

[John15321]

As a next step, I've opened a PR with a proposed pass at filling in the open X placeholders in the draft, based on what we discussed in the office hours (July 9, 14, and 16):

#2206

It's not final or perfect, but it's meant to make the proposed answers easy to review as a diff and discuss/iterate on before we move toward a final version. Please take a look and leave feedback, especially on anything that doesn't match what was actually agreed.