Committee Conflict of Interest resolution #7468
Conversation
justaugustus
changed the title
k8s-ci-robot
added
do-not-merge/work-in-progress
k8s-ci-robot
added
the
cncf-cla: yes
justaugustus
force-pushed
the
committee-coi
branch
from
06301ae
to
152db13
Compare
k8s-ci-robot
added
the
committee/steering
There was a problem hiding this comment.
Ready for review.
Committee members:
/cc @kubernetes/steering-committee @kubernetes/code-of-conduct-committee
Election subproject:
/cc @jberkus @parispittman @mrbobbytables @nikhita @fsmunoz
/retitle Committee Conflict of Interest resolution
/hold
k8s-ci-robot
added
the
do-not-merge/hold
k8s-ci-robot
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
@justaugustus: GitHub didn't allow me to request PR reviews from the following users: kubernetes/code-of-conduct-committee, kubernetes/steering-committee. Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
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. |
justaugustus
force-pushed
the
committee-coi
branch
from
abf2cb9
to
e8b10d7
Compare
k8s-ci-robot
added
size/L
|
Added a section about withdrawing the candidate from the second election to complete in b7fd89e. |
justaugustus
force-pushed
the
committee-coi
branch
from
b7fd89e
to
fcea472
Compare
justaugustus
requested review from
cblecker,
cpanato,
hlipsig,
tpepper,
jberkus and
palnabarun
|
/label tide/merge-method-squash |
k8s-ci-robot
added
the
tide/merge-method-squash
|
Overall +1, the one caveat that these should go in effect after our current round of elections conclude as they were not in place before either election was started. |
@mrbobbytables -- Could we instead set an effective date on the top of the doc for Monday, October 2 (Public announcement of Results at Public Steering Committee Meeting)? This issue has been around for two years and it would be great to not leave this languishing for much longer. 📿 |
|
Oh yeah, I'm fine with that - I was good with merging beforehand without a date in the doc as long as there was a general understanding they'd go in effect after this round of elections. |
Signed-off-by: Stephen Augustus <foo@auggie.dev>
|
@mrbobbytables -- okay, perfect. Added an effective date of 2023-10-03 (a day after the election results are announced). |
There was a problem hiding this comment.
The current version looks good!
Thanks, @justaugustus for working on this.
/lgtm
(with the steering hat)
k8s-ci-robot
added
the
lgtm
| - Standing Steering or CoCC members must have served on their committee for a | ||
| period of twelve (12) months to be considered eligible for candidacy in the | ||
| other committee's election |
There was a problem hiding this comment.
I like this sentiment, but I see a problem with the number 12 months, specifically in how the current elections are lined up. If the elections were staggered by 6 months, this would be completely reasonable, but if the elections are close together, as they are right now, and they happen at about the same time every year, this places an unbalanced restriction on the committee that has its elections first. Whatever the candidates reasons might be for wanting to change committees in the first place (for example: wanting more/less emotional labor), I would suggest this number change to slightly less (10 or 11 months), to not be such a unidirectional disadvantage. This would also avoid even the perception of any possible artificial forcing function pushing back the annual cycle of elections.
There was a problem hiding this comment.
As I'm thinking about this, we could also say slightly longer (14 months), and still avoid the imbalance when elections are close on the calendar.
| - Candidates who are nominated for a seat on both Steering and CoCC within the | ||
| same 12-month period must: | ||
| - (if elected) accept a seat on the committee whose election concludes first | ||
| - be withdrawn from candidacy in second election to conclude | ||
| - Standing Steering or CoCC members must have served on their committee for a | ||
| period of twelve (12) months to be considered eligible for candidacy in the | ||
| other committee's election | ||
| - Kubernetes Community members who have recently voluntarily vacated a seat on either | ||
| Steering or CoCC without serving the complete term will be ineligible for candidacy for a period of three (3) | ||
| months |
There was a problem hiding this comment.
So I'm going to challenge this a little bit, so I'm going to tag the folks who were suggesting something like this as I'd like their opinion (cc @katcosgrove @celestehorgan)
While I completely understand that we don't want folks jumping from committee to committee on a regular basis for reasons of continuity and burden on their fellow committee members, I fear that putting these kinds of hard restrictions on the election processes will have the possible unwanted side effects:
- Folks may choose not to run for a committee that they wish to serve on, because they might also hypothetically want to run in a different election within the 12 months if they are elected. This would have the effect of shrinking the possible candidate pools.
- These are unpaid, voluntary positions. Forcing someone to serve in a capacity that they no longer wish to is not only unfair to the individual, but it's unfair to the community as a whole who benefits from their service.
- Employer support for upstream work can change. While an employer may provide time to serve on one committee, they may not provide that time to serve on the other.. this again would hold someone in a position where they don't want to be.
I think in practicality, some of this could be reduced by having a greater staggering in the elections.. right now we have CoCC in August and Steering in September. If they were staggered more, then we wouldn't have any risk of concurrent election periods and less possibility of thrashing if folks move between committees. But having these long, forced ineligibility periods I feel puts strain on individuals who are serving the community in really important ways.
Very open to other suggestions that might better solve these issues.
There was a problem hiding this comment.
just curious, what is the spirit of this norm and why 3 months? it seems that it tries to avoid some specific thing to happen but I can´t understand what
There was a problem hiding this comment.
Our intent with this phrasing was that no potential for conflict exists until a committee position is actually held, so a candidate would be able to run for two positions within a 12-month period assuming they were not successful in their first attempt. If that's unclear, I'm happy to be more explicit!
The 3-month timeout period after voluntarily leaving your seat is there to discourage people from doing that simply to attempt to campaign for a seat on a more professionally lucrative committee. Allowing for committee hopping is especially problematic for the CoCC, where losing one member early is significantly more impactful than it is for Steering due to the much smaller committee size, but it's unfair to Steering as well and to the community at large due to the instability it causes. However, if we think the risk involved in voluntarily stepping down to run in another election the candidate may lose is deterrent enough without the 3-month timeout, I won't fight too hard to keep it. The individual should still be required to have served 12 months of their existing term before being eligible to run for a seat on another committee without first stepping down, though.
Staggering the elections more would certainly help solve this issue, but how doable is that in actual practice?
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cpanato, justaugustus, katcosgrove, palnabarun The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
needs-rebase
|
PR needs rebase. 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 contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
k8s-ci-robot
added
the
lifecycle/stale
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
k8s-ci-robot
added
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:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
|
@k8s-triage-robot: Closed this PR. In response to this:
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. |
This is a carry of @tpepper's #6243 / kubernetes/steering#224.
I still need to sweep the comment/review history from the previous PRs and resolve open concerns, but getting this up ASAP as a point for discussion (as election cycles are already underway).Part of kubernetes/steering#221
cc: @kubernetes/steering-committee @jberkus