steering
steering copied to clipboard
kubernetes
Resolving conflicts of interest with committee membership
Problem Statement
Affectionately termed the "@parispittman Provision" in the 2021-11-08 Steering meeting, there has been a precedent established for members of the @kubernetes/code-of-conduct-committee to step down from CoCC should they be elected to serve on @kubernetes/steering-committee.
From https://github.com/kubernetes/community/blob/master/committee-code-of-conduct/incident-process.md#incident-reporting-and-response-process:
The Code of Conduct Committee has unilateral power to address harms as needed and appropriate to restore community safety after any incident(s). We are separate from the Steering Committee and all other bodies in the Kubernetes community to provide a mechanism by which anyone can report, regardless of roles and organizational power dynamics which often lead to systemic underreporting.
In instances where the members of the Steering Committee are involved in Code of Conduct incidents, there is a clear conflict of interest.
Proposed Solution
- Accept and document the precedent that Steering members must not simultaneously serve on the CoCC
- Establish a decision tree for resolving membership "conflicts"
e.g.,
- Steering election happens
- A member of CoCC is elected to Steering
- Election committee reaches out to newly-elected member to resolve conflict. If:
- Newly-elected member plans to step down from CoCC, then a new CoCC member should be selected from the pool of ranked candidates from the previous CoCC election
- Newly-elected member prefers to remain on CoCC, then the election committee would select a Steering member from the pool of ranked candidates
- Results are announced, including the resolution of the committee membership conflict
If a seated Steering member elected to run for CoCC, I imagine that we [c|sh|w]ould have the same rules apply.
cc election officials of elections past: @alisondy @jberkus @coderanger @idvoretskyi @jdumars @mrbobbytables @castrojo
From @jberkus in https://github.com/kubernetes/steering/issues/271:
It has been de-facto Steering Committee policy for the last 2+ years that nobody can be on both the CoCC and the SC at the same time. However, this isn't documented in either the SC or the CoCC election materials, rules, or bylaws. As a result, this month we have someone who is running for both offices. Because, why shouldn't they?
Proposed Solution
Both the CoCC and the SC candidate materials should clearly spell out that you can't be on both bodies at once.
Open Questions
Can someone run for both, and only accept one? If so, under what circumstances?
Next Steps
- [ ] Steering to write final CoCC/SC conflict policy
- [ ] Steering to direct CoCC and Elections subproj to add that to documentation
@celestehorgan has noted https://github.com/kubernetes/community/blob/master/committee-code-of-conduct/bootstrapping-process.md
We definitely need to consider the historical context and intents in updating process docs across CoCC and Steering around membership, but also likely should archive this document so the repo state is clear and consistent with the present/chosen operationalization.
When there are a lot of candidates, I really like the idea of next in line from the last election and then that person fills the term of the vacant seat instead of doing a new election. This would follow the same rules as Steering and maintain consistency. The individual filing the vacant seat can run again in the next election.
FWIW, I don't think the ECs should have an opinion on this; our authority ends when the election is over.
Otherwise, I'd +1 the suggested process.
Following @justaugustus's suggested text which feels reasonable, I'm proposing some clarifying text to the elections.md docs for both the Steering and Code of Conduct Committees to formalize our existing practice of stepping down and the vacancy being filled.
Proposed changes from Tim in https://github.com/kubernetes/steering/pull/224 and https://github.com/kubernetes/community/pull/6243.
Proposed changes from Tim in #224 and kubernetes/community#6243.
Thanks for linking, I should have explicitly. I'm used to the GitHub web view and was appending my comment in the event stream there, but for folks' inbox event stream my comment left insufficient context.
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
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
Resurrecting this as it's come up as part of the 2023 election cycles. ref: https://kubernetes.slack.com/archives/C03PY5263LN/p1692058006711979 / https://github.com/kubernetes/steering/issues/271
/assign /unassign @tpepper @parispittman