SC Elections: Consider whether candidates should be required to meet voter requirements
jberkus opened this issue · comments
Per the 2021 Election Retro:
Currently, candidates for Steering are not required to meet voter eligibility requirements in order to run. This has led to the odd situation in some elections where a candidate was unable to vote for themselves (or anyone else) and no such candidates have ever been elected.
The SC should consider whether being an eligible voter (whether by contributions, exception, or committee membership) should become a requirement in order to run for SC.
@kubernetes/steering-committee to leave comments (particularly @cblecker for historical context on decision)
(from 12/6 Steering public meeting)
short history:
This was something that was discussed by the bootstrap committee, either that we could restrict who could run for election, or restrict who can vote.. restricting both may be unnecessary or redundant. It was originally thought that if we restrict who can vote, but leave who can run fairly open (with a small nomination bar) that we will be able to have the best folks get the job. There might be a future where the community decides they want an outside voice on the SC.
my own thoughts:
I agree with that historical precedent, even though this may create situations where a candidate can run, but not be able to actually vote for themselves.
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
/remove-lifecycle stale
@parispittman @tpepper @liggitt @dims @mrbobbytables @parispittman any thoughts on this? Would like a determination that we're not going to change anything.
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
Given the inertia on this, I'm going to close it WONTFIX.
/close
@jberkus: Closing this issue.
In response to this:
Given the inertia on this, I'm going to close it WONTFIX.
/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.
/remove-lifecycle stale
/reopen
Discussed at today's Steering meeting
ref: https://docs.google.com/document/d/1qazwMIHGeF3iUh5xMJIJ6PDr-S3bNkT8tNLRkSiOkOU/edit#bookmark=id.ld1rkuodbcix, https://kubernetes.slack.com/archives/CPNFRNLTS/p1658166875780979
@justaugustus: Reopened this issue.
In response to this:
/remove-lifecycle stale
/reopenDiscussed at today's Steering meeting
ref: https://docs.google.com/document/d/1qazwMIHGeF3iUh5xMJIJ6PDr-S3bNkT8tNLRkSiOkOU/edit#bookmark=id.ld1rkuodbcix, https://kubernetes.slack.com/archives/CPNFRNLTS/p1658166875780979
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.
Per discussion above, this was settled in favor of not changing the rules. Is there some specific reason why it needs to be revisited?
Discussed further in steering slack.
Feedback from steering:
Thinking about it and re-reading my previous comment, I don’t think a change here is required. I’m fine with the “running for election” being different than “eligible voters” list.. especially because we still have the check where three different folks from three different employers need to endorse the candidate, and those endorsing folks need to be eligible voters themselves
I tend to agree with remaining less restrictive, especially if the only issues encountered because of the current permissive candidate requirements have been of the "that seems a little weird" variety. The "Beware the trap of SC getting to decide who can and cannot be on SC" note from the last public discussion resonated with me, since steering determines voter eligibility guidelines.
In practice, it's really only be used to consider the number of contributions to weight the wanting voters to have some “skin in the game” as it were, but still have a voting pool that is representative of the community. I think it's been fairly stable for a number of years though, so I'd be open to codifying it a bit more. But maybe that's something the elections subproject can take on?
yeah, I see this punting to elections subproject unless we can get a change we all agree to in less than ~20-25 days. may the odds be in everyone's favor until then?
I agree after revisiting the historical context, regarding the voting body I think the general thought was making a change to auto-include committess and potentially sig/wg leads, those that are (potentially) not likely to have as many github recorded stats (e.g. CoCC members)
Sounds like 4/7 didn't think a change to this was needed at this time, so resolving this with no action.
/close
@liggitt: Closing this issue.
In response to this:
Discussed further in steering slack.
Feedback from steering:
Thinking about it and re-reading my previous comment, I don’t think a change here is required. I’m fine with the “running for election” being different than “eligible voters” list.. especially because we still have the check where three different folks from three different employers need to endorse the candidate, and those endorsing folks need to be eligible voters themselves
I tend to agree with remaining less restrictive, especially if the only issues encountered because of the current permissive candidate requirements have been of the "that seems a little weird" variety. The "Beware the trap of SC getting to decide who can and cannot be on SC" note from the last public discussion resonated with me, since steering determines voter eligibility guidelines.
In practice, it's really only be used to consider the number of contributions to weight the wanting voters to have some “skin in the game” as it were, but still have a voting pool that is representative of the community. I think it's been fairly stable for a number of years though, so I'd be open to codifying it a bit more. But maybe that's something the elections subproject can take on?
yeah, I see this punting to elections subproject unless we can get a change we all agree to in less than ~20-25 days. may the odds be in everyone's favor until then?
I agree after revisiting the historical context, regarding the voting body I think the general thought was making a change to auto-include committess and potentially sig/wg leads, those that are (potentially) not likely to have as many github recorded stats (e.g. CoCC members)
Sounds like 4/7 didn't think a change to this was needed at this time, so resolving this with no action.
/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.