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 (kubernetes/steering#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

[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

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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

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

[mrbobbytables]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[ehashman]

/remove-lifecycle stale
/lifecycle frozen

[jberkus]

/area elections

[justaugustus]

/assign
(from 12/6 Steering public meeting)

[tpepper]

Something mentioned by @jberkus today was an idea of having the specific org in question meet (privately?) to decide (criteria ambiguous?) which subset of their elected folks would carry on after exceeding the maximal representation. I very much dislike this. I dislike this concept. It feels contrary to https://github.com/kubernetes/steering/blob/main/elections.md#limiting-corporate-campaigning.

Another item mentioned was that perhaps somebody from that org, previously elected was behind on their contributions to the committee, and would step down allowing their company peer an in. If this is the case, I believe they should step down and that should not be coordinated with a peer from their company running. Ideally that "I'm behind and should step down" realization would also not follow an election. Otherwise you're again going against the idea that Steering Committee members are representing the community not their employer.

I feel like this is a variation on kubernetes/steering#221, which could be treated generically for any possible representation conflict. Initially I tried to word it broadly. But it does specifically include retroactively seeing the conflict has arisen and addressing it. That is by design to allow people the flexibility/choice to aim for opportunities they want to pursue. The risk of companies doing some sort of self-dealing is hard to preclude, and it's better to not be so harsh against that possibility that real individual aspirations are also shut out.

[cblecker]

I agree with @tpepper 's thoughts here mostly. I'm not sure how the conflict of interest issue would apply here, but the idea that multiple members of a specific employer would meet and decide who would take the seat doesn't align with the idea that the community chooses its representatives.

If a particular member of the SC wishes to step down for some reason, my suggestion would be they just do so and we resolve that vacancy per our normal policies. I don't think it aligns with our intended values to have the concept that someone would step down from SC, but only if they can pass on their seat to someone specific from the same employer. I could also see some possible really bad situations where multiple folks from the same employer are elected and the person who has a more senior job title or is higher up in a reporting chain pressures or directs one of the other candidates or seated members to step down.

Unless there are some convincing arguments about why we should do this, I would vote to close with no change to the current policy.

[jberkus]

So that sounds like a -1. If someone from the SC wants to close this, that will decide it.

[dims]

@tpepper @justaugustus @cblecker so we close this? (+1 to what @cblecker said)

[cblecker]

+1 to close

[jberkus]

/close

[k8s-ci-robot]

@jberkus: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.