[DO NOT MERGE THIS] DEADLINE IS JULY 23RD 2026!#2206
Conversation
Signed-off-by: Jan Bronicki <janbronicki@gmail.com>
| The nomination period is X. | ||
| The nomination period is measured in weeks rather than months, to fit Flatcar's | ||
| smaller scale (closer to Istio's timeline than Kubernetes'). The exact number of weeks | ||
| is X. |
There was a problem hiding this comment.
I would say 3 weeks, hopefully longer than the longest vacation.
|
|
||
| The voting period is X. | ||
| The voting period is likewise measured in weeks rather than months. The exact number | ||
| of weeks is X. |
There was a problem hiding this comment.
4 weeks after the close of nomination? This should give the nominees time to produce a document with their priorities / goals?
|
@mrbojangles3 Thank you for looking into this! |
| The exact company representation rule is X. | ||
| The exact company representation rule is X *(founding-term seats are not subject to a | ||
| same-company limit; a rule for subsequent terms is part of the founding mandate — see | ||
| "Founding mandate" above)*. |
There was a problem hiding this comment.
This means the founding 5 seats have no company cap at all and the group elected under no cap is the same group that later decides what the cap should be. This is the exact area CNCF tends to scrutinise during graduation review whether governance is genuinely open and neutral and it lines up directly with our MSFT heavy maintainer mix. Can we lock in a starting percentage now, like we discussed, closer to 38 percent, rather than leaving this fully open until after the committee already exists?
There was a problem hiding this comment.
- Lets do the cap for steering 38%, and a minimal (aka loose) cap for technical 4/5 can be from the same company
- For the first committee (steering) the cap is 2/5 from the same company max - because for the first one we , then during normal operation of the committee it can be max 1/5 from the same company
| community members/users only, not to Maintainers or Contributors). | ||
| - **Voter eligibility:** all Maintainers and Contributors are eligible to vote. | ||
| Active, recognized community members/users may also vote if they request voting | ||
| rights and are approved by the Maintainer Council. |
There was a problem hiding this comment.
should this go to steering once it exists rather than maintainer council? kubernetes and istio both route exceptions through the elected body itself, keeping it with maintainers might read as old structure holding onto authority
There was a problem hiding this comment.
Will be solved in https://github.com/flatcar/Flatcar/pull/2206/changes#r3622019188
| For the founding term, the Steering Committee works by full consensus: with only 5 | ||
| seats, all 5 members must agree for a decision or charter change to pass. If a member | ||
| is absent or the seat is vacant, consensus is required among the remaining seated | ||
| members. |
There was a problem hiding this comment.
The full consensus with 5 people means one person can block the founding mandate, including the rules we need finished before graduation. Given the timeline that feels risky to me. I would push for majority or supermajority instead, even just for founding term.
There was a problem hiding this comment.
- yeah it wasnt supposed to be, please fix it
| candidate(s) from other companies (following Kubernetes' approach). | ||
|
|
||
| If the project adopts separate seat categories, the rules for how same-company limits | ||
| apply across those categories are X. |
There was a problem hiding this comment.
same open question as the cap above, might be worth resolving these together rather than leaving two open versions of the same gap in different docs
| - **Candidate eligibility:** any Maintainer or recognized Contributor is automatically | ||
| eligible to stand. Known and active community members/users are also eligible, but | ||
| only after passing a vetting process run by the Maintainers (this vetting applies to | ||
| community members/users only, not to Maintainers or Contributors). |
There was a problem hiding this comment.
The vetting process for community members/users isn't defined anywhere, what does it actually check? Right now this reads as maintainers automatically in, everyone else through an unwritten process. Probably want at least a few concrete criteria here before this gets adopted.
There was a problem hiding this comment.
The person should have multiple meaningful contributions (both technical and non technical) within the last year
@LexiNadolski will update this
| ### Escalations | ||
|
|
||
| Escalations are used to resolve misalignments and are always agreed on by involved | ||
| parties. *All parties* must at a minimum agree on the fact that a blocking problem |
There was a problem hiding this comment.
"all parties must agree a blocking problem exists" means if someone IS the problem they can just not agree, and escalation never triggers. This feels like it shouldn't require full agreement just to acknowledge something's blocked.
| ### Founding mandate | ||
|
|
||
| In addition to the responsibilities above, the founding-term Steering Committee is | ||
| specifically tasked with defining, before its term ends, the rules that will govern |
There was a problem hiding this comment.
Mandate just says "before its term ends" with no earlier checkpoint. Given how hard we've had to push for people to actually engage, worried this ends up rushed right at the deadline with no real room for public comment. Maybe a mid term checkpoint, month 9 or 10ish, so there's an actual draft out before the wire?
|
|
||
| A Steering Committee member may be removed by X. | ||
|
|
||
| The process for initiating and recording such a removal is X. |
There was a problem hiding this comment.
This is X for the whole founding term so there's no way to remove someone for a full year if they go inactive or become a real problem. Founding term feels like exactly the phase we'd want this covered not skip.
There was a problem hiding this comment.
- just copy istio and other preojct
|
Also @John15321 I didn't see a deadline for review here? Did I miss it? |
My bad, I expressed it verbally and in some other places. The deadline would be this Thu |
John15321
changed the title
3 participants
What this is
This PR is a proposed response to the open
Xplaceholders indraft.md, based on the discussions we had during the Flatcar governance office hours (July 9, 14, and 16, 2026) and the async feedback collected alongside them.It's my attempt to turn those discussions into concrete language for the Steering Committee and Technical Committee charters (founding term parameters, eligibility, terms, voting thresholds, election method, meeting cadence, amendment process, etc.). It's not perfect and not final — I did my best to capture what was discussed, but some points may still need correction or further debate.
I opened this as a PR (rather than editing the doc directly) so the proposed changes are easy to review as a diff, discuss inline, and iterate on. The goal is to get us closer to a ready, mergeable governance document — not to merge this as-is (hence
[DO NOT MERGE THIS]).Background / references
Feedback welcome
Please review and comment — especially on anything that doesn't match what was actually agreed in office hours, or any
Xthat's still ambiguous.