Resolving conflicts of interest with committee membership

[justaugustus]

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 #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

[justaugustus]

/assign @parispittman @tpepper

[tpepper]

@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.

[dims]

+1 to the proposed solution.

[parispittman]

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.

[liggitt]

+1 as well

[jberkus]

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.

[celestehorgan]

cc: @kubernetes/code-of-conduct-committee

[tpepper]

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.

[justaugustus]

Proposed changes from Tim in #224 and kubernetes/community#6243.

[tpepper]

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.

[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

[tpepper]

/remove-lifecycle stale

[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

[justaugustus]

/remove-lifecycle stale
/lifecycle frozen

[justaugustus]

Resurrecting this as it's come up as part of the 2023 election cycles.
ref: https://kubernetes.slack.com/archives/C03PY5263LN/p1692058006711979 / #271

/assign
/unassign @tpepper @parispittman