community
community copied to clipboard
kubernetes
update code of conduct charter to address other committee elections
Over the course of the code of conduct committee's existence, we have seen a number of members run for steering while serving on the committee. In the event that they are elected, they resign from code of conduct (serving on both would be a conflict of interest). This does however create the potential for high turnover on code of conduct if many members end up making that a stepping stone to steering.
I am proposing this charter change to encourage elected members to remain with code of conduct through their committed term.
/hold /cc @kubernetes/steering-committee /label committee/steering
Explicit hold as all charter changes require steering review
@cblecker: The label(s) `/label committee/steering
cannot be applied. These labels are supported:api-review, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, team/katacoda, refactor. Is this label configured under labels -> additional_labelsorlabels -> restricted_labelsinplugin.yaml`?
In response to this:
/hold /cc @kubernetes/steering-committee /label committee/steering
Explicit hold as all charter changes require steering review
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.
Compared to stated intent in the PR description, I'm not sure I see in the charter change a strong incentivize for that outcome. Pondering if/how we might more strongly....
@tpepper I don't think we want to stop people from doing so if that's what they desire, but want to make it less of a... "tossing the hat in the ring and then making a decision" (which is fairly disruptive to both of our election processes), but more "committing to staying on the CoCC or running for steering".
To the discussion above, I might suggest updating the PR body re:
I am proposing this charter change to encourage elected members to remain with code of conduct through their committed term.
To also note the positive effect of ensuring a predictable transition period if members do go forward with running anyhow.
Just for anyone coming across this later.
/hold /cc @kubernetes/steering-committee /label committee/steering
Explicit hold as all charter changes require steering review
I may want to add this statement to the charter as part of this too then. Currently it states "Any changes to the charter require explicit LGTM or Approve from all committee members. For pull requests, a /hold will be applied until all approvals are present. Any changes merged without consensus will be reverted". I think it makes total sense to have approval from steering as well, I just want to be sure that requirement is documented.
@salaxander Yes, it might make sense to call that out. You could link it to https://github.com/kubernetes/community/tree/master/committee-steering/governance#sig-charter-approval-process which is the relevant section in the governance docs
Counter-argument: recruiting folks for CoCC at all is very difficult, and the pool of potential CoCC members has like 70% overlap with the pool of potential SC members. Are we sure that we want to position things so that potential candidates say "hmmm, I don't want to run for CoCC because I might want to run for SC next year"?
Counter-argument: recruiting folks for CoCC at all is very difficult, and the pool of potential CoCC members has like 70% overlap with the pool of potential SC members. Are we sure that we want to position things so that potential candidates say "hmmm, I don't want to run for CoCC because I might want to run for SC next year"?
I think that's a valid concern. Maybe we as the current committee need to do a better job of sourcing candidates for future roles? As it is though, the high turnover and lack of continuity ends up being quite disruptive to the code of conduct committee. I'm open to exploring other options, but we really would like to find a way to ensure that we don't find ourselves in a situation like the current one again (every member of the committee is new)
The thing I’ve been trying to figure out: how do we incentivize finishing out terms? Admittedly I didn’t on CoCC myself. And while I feel like I need to go back and deliver on that commitment, it wont be easy: to stand for next year’s 2023 CoCC election I’d have to step down early from SC. Or I would need to not stand for 2023 SC reelection and and then wait ten months for 2024 CoCC (re)election. That wouldn’t be helped by first stepping off CoCC per the idea here, and like Josh notes it looses one or both bodies a volunteer. It might only be helped by us individually realizing we need to be finish commitments before aspiring to or taking on next ones. That’s hard to incentivize, especially constructively vs punitively.
Still feels punitive, but would it be more effective to say committee candidacy does not include ones who did not complete a prior committee commitment in the (~1year?) lead up to the committee election?
Top of head thought: would it make this problem better/worse/no change if we aligned the election cycles between the committees
Top of head thought: would it make this problem better/worse/no change if we aligned the election cycles between the committees
Currently, the SC elects the CoCC. So that would shift to having the "lame duck" SC elect them. Which isn't necessarily a blocker, but is a shift in who selects what.
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.
This bot triages 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 PR is closed
You can:
- Mark this PR as fresh with
/remove-lifecycle stale - Close this 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 PRs.
This bot triages 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 PR is closed
You can:
- Mark this PR as fresh with
/remove-lifecycle stale - Close this PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
@Chiefy0x1: changing LGTM is restricted to collaborators
In response to this:
/LGTM
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.
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Chiefy0x1, detiber, endocrimes, salaxander
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~committee-code-of-conduct/OWNERS~~ [endocrimes,salaxander]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
@endocrimes: The lifecycle/frozen label cannot be applied to Pull Requests.
In response to this:
/lifecycle frozen
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.
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.
This bot triages 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 PR is closed
You can:
- Mark this PR as fresh with
/remove-lifecycle rotten - Close this PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages 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 PR is closed
You can:
- Reopen this PR with
/reopen - Mark this PR as fresh with
/remove-lifecycle rotten - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close
@k8s-triage-robot: Closed this PR.
In response to this:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages 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 PR is closedYou can:
- Reopen this PR with
/reopen- Mark this PR as fresh with
/remove-lifecycle rotten- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/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.