Community: Refine rules on exceeding maximal representation for SC election

[jberkus]

Steering:

The Way It Is Now: According to the steering committee elections doc,

If the results of an election result in greater than 1/3 representation, the lowest vote getters from any particular company will be removed until representation on the committee is less than one-third.

This means that, if there is already one SC member from CompanyX not up for election, and two new people from Company X win the current election, the least preferred newly elected candidate is automatically discarded. In a worst case, if there are two contributors working for CompanyX already on the SC, there is no point in anyone from CompanyX running for SC at all.

Proposed Change:

If the results of an election result in greater than 1/3 representation, the existing and newly selected steering members from the overrepresented employer will be given the opportunity to choose, by consensus, one of their number to step aside. If they do not so choose, the least preferred candidate in the current election from any particular company will be removed until representation on the committee is less than one-third. If an existing member not up for election chooses to step aside, then all candidates will be considered to fill the resulting vacancy in the order of their preferred vote ranking.

This would allow more flexibility, and would allow an SC member who works for CompanyX to say, "hey, if my coworker was elected, I'm OK with resigning the committee."

/committee steering
/sig contributor-experience

[cblecker]

Question to election officers: is this something we want to change midway through an election cycle? My gut says that is a bad idea, and it would be preferable to discuss this in a retrospective between cycles.

Additionally, this could introduce some complexities around committee continuity where more seats are technically "up for election" than either the 3 or 4 that are supposed to be each cycle. There is also considerations about how this would interact with the term limits proposal (https://github.com/kubernetes/steering/issues/127).

[derekwaynecarr]

I agree with @cblecker that we should only update election rules between election cycles, and so we should queue this up for discussion prior to next election.

[jberkus]

Well, the reason I bring this up is that we potentially have exactly this situation with this election, with folks who are employed by VMware.

Regardless, we should NOT wait until "just before the next election". We did that with the nominations process, and as a result the new EC had no idea whatsoever that they were supposed to change something. If we're going to make this change between elections, we should do it right after this election.

[jdumars]

+1 to what Josh said. I think this is a defect in the process as it stands now, and should be addressed explicitly before results are tallied. Having more clarity here is not a risk in my opinion.

[cblecker]

Is this an issue of clarifying the current rules, or changing them? What I read from Josh's issue is that this would be a change to the rules, as the interpretation of "The Way It Is Now" is what I understood to be the case, and the rules used in the 2019 election

[jberkus]

@cblecker I'm not even sure whether this is just a clarification or requires an actual change to the rules.

[dims]

/assign

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[nikhita]

/remove-lifecycle stale