search

kubernetes / steering

The Kubernetes Steering Committee
Apache License 2.0
86 stars 61 forks source link

charter: Add sections on membership, resignations, and removals #248

Closed parispittman closed 2 years ago

parispittman commented 2 years ago

Charter updates including:

Membership

Voting

Meetings

(Content inspired by the language in the TOC charter. )

From @justaugustus in https://github.com/kubernetes/steering/pull/248#issuecomment-1170675201:

Per our change process, notice has been delivered on the Steering mailing list: https://groups.google.com/a/kubernetes.io/g/steering/c/JxZthc8HcXM/m/NLaDpmbbAQAJ

dev@ has been additionally cc-ed: https://groups.google.com/a/kubernetes.io/g/dev/c/AU2zqLAsx1k/m/SR_eQlx6AAAJ

Votes

No

Yes

parispittman commented 2 years ago

/hold for reviews

justaugustus commented 2 years ago

Per our change process, notice has been delivered on the Steering mailing list: https://groups.google.com/a/kubernetes.io/g/steering/c/JxZthc8HcXM/m/NLaDpmbbAQAJ

dev@ has been additionally cc-ed: https://groups.google.com/a/kubernetes.io/g/dev/c/AU2zqLAsx1k/m/SR_eQlx6AAAJ

justaugustus commented 2 years ago

(no-op push to fixup commit message.)

markjacksonfishing commented 2 years ago

/lgtm Or at the very minimum, a consensus

jdumars commented 2 years ago

/lgtm once Election Policy link is in place

Future to do: mention the elections subproject as specific owner vs. SIG-contribex once it's established.

jdumars commented 2 years ago

thanks for the update!
/lgtm

dims commented 2 years ago

NOTE for readers, the two-thirds as paris said is from TOC charter https://github.com/cncf/foundation/blob/main/charter.md where it says:

TOC members may be removed by a two-thirds vote of the other TOC members, with the impacted individual ineligible to participate in the vote.

https://opensource.org/bylaws also has similar language:

A director may be removed from the Board at any time prior to the expiry of such director’s term for any reason by a vote of two thirds of the authorized members of the Board

Please see links for full context of the snippets i pasted

dims commented 2 years ago

@parispittman and other steering folks,

After talking to a friend and sleeping on it, i think it would be good to run a special election for the specific removal scenario as it removes the temptation for steering folks to vote off someone just because they like the person who is runner up. Please consider adapting the language in the PR to do this.

dims commented 2 years ago

Couple observations:

  1. Kubernetes follows a two-thirds supermajority vote for most decisions, but worth considering for removals to require a unanimous vote for the exception of the unseated.

Andres, i hear you. What's here in the PR is a combination of what we already do (next-person-up!) and picking things from established precedents in terms of language (two-thirds).

  1. With the intent to preserve a degree of stability and foresight in the project direction in the event of a removal, it may also be worth considering introducing a period of time over which no more than one member can be involuntarily unseated. For example. no more than one member may be unseated over a 3 month period.

i like the way you think about more than one ... but this seems artificial somewhat. BUT i would love to see other existing charters where this is enshrined so we can learn from it. (don't want to over engineer this more than what's already out there)

thanks Andres!

sbueringer commented 2 years ago

/lgtm

AevaOnline commented 2 years ago

@dims wrote:

i think it would be good to run a special election for the specific removal scenario as it removes the temptation for steering folks to vote off someone just because they like the person who is runner up

@dims, I can understand this concern and recognize the precedent from popular elections, though I am not aware of any technical communities (open source or otherwise) that follow this method (I would be happy to learn of, and from, any that do). I think this concern could be solved by instead requiring the election committee not disclose the ordered runner-up list after an election; is that feasible?

As written, it would allow SC to address unresolvable internal conflicts without necessarily making the details public, which would be necessitated if a popular special election were required. I believe that is why an internal vote (either requiring a 2/3 majority, or requiring consensus) is the norm in similar bodies.

dims commented 2 years ago

@AevaOnline our election votes/raw result have been public for a VERY long time. We keep it quiet and don't draw attention to it. but it's available if one goes looking. I don't see us changing this rule anytime soon.

I hear you about other communities, so i am asking folks to think about this situation.

deads2k commented 2 years ago

After talking to a friend and sleeping on it, i think it would be good to run a special election for the specific removal scenario as it removes the temptation for steering folks to vote off someone just because they like the person who is runner up. Please consider adapting the language in the PR to do this.

Special elections rarely have representative turn out, so holding such an election seems likely to skew outcomes unnecessarily given an election from within the last year. I would rather see guidance for the steering committee regarding what acts and thresholds should be considered when deciding how to cast a vote for removal.

vincepri commented 2 years ago

/lgtm

dims commented 2 years ago

@anvega pointed me to https://github.com/spiffe/spire/blob/main/MAINTAINERS.md#changes-in-maintainership (thanks Andres)

justaugustus commented 2 years ago

As a general note, I am a coauthor of this PR and the updates I've made are with the permission of my coauthor.

I've pushed some updates to try to incorporate the feedback we've received both here and in other discussions:

While it is not complete, I've captured remaining discussion items as TODOs in the relevant sections.

cc: @kubernetes/steering-committee

lavalamp commented 2 years ago

Sorry for all the comments, but this kind of thing is quite hard to write if you assume some unknown party|ies on the board is/are not functioning correctly! Very much like apiservers operating in a split-version configuration... 🤔

Unlike with e.g. byzantine considerations for blockchains, the goal is NOT to maximize the number of malicious parties the board can tolerate and still function. Since the community might well have deliberately elected representatives from different "factions" (not speaking of the current board AFAIK).

I think the threat vector to defend against is a single rogue board member. If the problem is worse than that, e.g. if multiple board members are "rogue", they may be there deliberately and IMO the community needs to settle that via a new vote. I think it'd be extremely bad if a majority of the board can kick off a minority by doing this process several times.

Therefore I think the threshold for this action should be unanimity (sans target) the first time it happens, and I'm not sure we should let it happen more than once between elections.

(I am assuming the recall election idea is going to be removed since the feedback is pretty solidly against it, and it will go back to some sort of board action.)

An alternative idea is, in this case, instead of ejecting someone or having an extra election, have the next election early and make sure the person in question's seat is included. This adds some risk to the board members invoking this, which I think is kind of healthy for a contentious action like this.

justaugustus commented 2 years ago

We've heard your feedback about minimizing the diff here, as well as simplifying the process e.g., dropping recall in the proposed changes.

In the set of commits I've just pushed, we've done the following:

The current draft proposes the following simplified process:

Thanks again for working with us as we iron the process out!

dims commented 2 years ago

@parispittman @justaugustus please consider the following in the Resignation section.

In case one-half or more of the steering members resign at the same time, the entire steering committee will be disbanded and fresh elections will be called. The steering committee members at the time will not be allowed to run in the new election.

Rationale: So, we never even imagined we would be in this position where we would have to do this process of "no confidence" on a duly elected member of the steering committee and look where we are today. So let's take this a step further to add this new twist where the steering has splintered into factions and has become totally useless to do its job in service of the community. In this case, the typical quorum/majority requirements become meaningless and we need a fresh start, so we go back to the community and ask them to pick an entirely new set of folks to re-seed the steering committee. If you wish we can also say "top 4 members will be elected for 2 year term and the bottom 3 will be for 1 year term", so we would then also end up with the yearly rotation as we have usually.

thanks, Dims

justaugustus commented 2 years ago

I've pushed a few more changes:

There are a few more review comments that I can see that need consideration:

Please feel free to call out anything glaring that I've missed in that list.

dims commented 2 years ago

Folks, Please come on over to the next steering meeting this thursday! - https://groups.google.com/a/kubernetes.io/g/steering/c/6rWHMZ5-vxw/m/gj-ncJcGAwAJ We can do a quick check of what is under contention and where we have consensus.

At some point those of us on the steering have to be able to vote on something concrete! we can't do that with the constant churn.

lavalamp commented 2 years ago

@dims you can't vote on this until it's been 4 weeks from the announcement anyway, IIUC the change rules correctly.

(They aren't clear enough -- I could see someone reading it as meaning 4 weeks from when the final revision to the change proposal is made)

justaugustus commented 2 years ago

(Latest force-push was to collapse the 20-commit history to something more manageable in case these sections need to be handled in multiple PRs. Reviews remain to be addressed in future commits.)

justaugustus commented 2 years ago

(Latest force-push was to collapse the 20-commit history to something more manageable in case these sections need to be handled in multiple PRs. Reviews remain to be addressed in future commits.)

The commits to-date, were squashed from 20 to 3, reordering some of the content to make it easier to pull content around the current elections process into a separate PR.

The recent pushes address the following areas:

I believe there are some voting numbers to still workshop, but again, feel free to call out anything I might've missed (outside of that).

dims commented 2 years ago

please also see https://github.com/kubernetes/steering/pull/249

dims commented 2 years ago

@dims you can't vote on this until it's been 4 weeks from the announcement anyway, IIUC the change rules correctly.

So looks like we are shooting for July 27 for the Steering to vote on this PR.

justaugustus commented 2 years ago

please also see #249

Heh, I was just about to link! For passerbys, #249 contains only the (roughly) no-op commits at the front of this PR to separate some of the cleanup from the new content.

jberkus commented 2 years ago 
2. With the intent to preserve a degree of stability and foresight in the project direction in the event of a removal, it may also be worth considering introducing a period of time over which no more than one member can be involuntarily unseated.  For example. no more than one member may be unseated over a 3 month period.

There are a lot of additional refinements needed to the intial removal policy. As another example, it fails to consider the circumstance where two SC members need to be removed at the same time for the same cause.

As such, I think we should pass a bare-bones removal process here, and then work out refinements over the next few months for a more complete policy that covers likely contingencies.

justaugustus commented 2 years ago

A few things...

It looks like there are a few more comments to address, but I've removed/deferred the more discussion-heavy sections which do not appear to be absolutely required for this iteration.

justaugustus commented 2 years ago

A few more things have been added...

Looking at what remains uncollapsed/unresolved by GitHub (and what has not been deferred to https://github.com/kubernetes/steering/pull/249), the remaining items are:

We can spend some time in today's meeting discussing, but also, do feel free to comment here (specifically on these points) in the meantime.

If you would like to discuss other topics that arose from these proposed changes, please do so on https://github.com/kubernetes/steering/pull/249.

This stuff is tricky, so thank you to everyone that provided helpful feedback here!

justaugustus commented 2 years ago

Current status:

Remaining:

dims commented 2 years ago

How far down the stack of previous runners we go before considering a special election?

proposal : each year we vote in either 3 or 4 candidates. So i'd say if we have to go more than 2 down the stack then we just hold a special election (so at most select 2 from the stack).

Should we not fill vacancies if the vacancy happens within N time of the next election?

proposal : i think we should strive to fill vacancies whenever they occur (at most 2 down the stack), however, if the vacancy is within a month of an election (of start of an election cycle), it probably would not help bringing on a new person and build a shared context.

kikisdeliveryservice commented 2 years ago

How far down the stack of previous runners we go before considering a special election?

proposal : each year we vote in either 3 or 4 candidates. So i'd say if we have to go more than 2 down the stack then we just hold a special election (so at most select 2 from the stack).

Should we not fill vacancies if the vacancy happens within N time of the next election?

proposal : i think we should strive to fill vacancies whenever they occur (at most 2 down the stack), however, if the vacancy is within a month of an election (of start of an election cycle), it probably would not help bringing on a new person and build a shared context.

2 down the stack feels arbitrary and doesn't account for the % of votes or skew between one or both of the next 2 and the 3-4 members seated from the election. If you took the top 4 and the skew between the 5th and the 4th is small but the skew between the 4/5th and the 6th is huge... it doesn't feel very representative of the community's will. It makes more sense to go down the stack so long as the candidates are within X% of the last seated candidate otherwise hold a special election.

I think these two are potentially sub-optimal outcomes: 1.2..3..4.5.................6 or 1..2.3.4..........5...........6

In both cases an election for 1 seat and 2 seats respectively might make more sense.

justaugustus commented 2 years ago

How far down the stack of previous runners we go before considering a special election?

proposal : each year we vote in either 3 or 4 candidates. So i'd say if we have to go more than 2 down the stack then we just hold a special election (so at most select 2 from the stack).

Should we not fill vacancies if the vacancy happens within N time of the next election?

proposal : i think we should strive to fill vacancies whenever they occur (at most 2 down the stack), however, if the vacancy is within a month of an election (of start of an election cycle), it probably would not help bringing on a new person and build a shared context.

2 down the stack feels arbitrary and doesn't account for the % of votes or skew between one or both of the next 2 and the 3-4 members seated from the election. If you took the top 4 and the skew between the 5th and the 4th is small but the skew between the 4/5th and the 6th is huge... it doesn't feel very representative of the community's will. It makes more sense to go down the stack so long as the candidates are within X% of the last seated candidate otherwise hold a special election.

I think these two are potentially sub-optimal outcomes: 1.2..3..4.5.................6 or 1..2.3.4..........5...........6

In both cases an election for 1 seat and 2 seats respectively might make more sense.

Agreed w/ @kikisdeliveryservice that we need to consider skew here. cc: @jberkus @parispittman (for thoughts)

justaugustus commented 2 years ago

proposal : i think we should strive to fill vacancies whenever they occur (at most 2 down the stack), however, if the vacancy is within a month of an election (of start of an election cycle), it probably would not help bringing on a new person and build a shared context.

Hmmmm, thinking about it again, I think I would be fine with:

dims commented 2 years ago

proposal : i think we should strive to fill vacancies whenever they occur (at most 2 down the stack), however, if the vacancy is within a month of an election (of start of an election cycle), it probably would not help bringing on a new person and build a shared context.

Hmmmm, thinking about it again, I think I would be fine with:

  • max two down the stack, but only on the basis that:

    • the next most preferred candidate cannot serve due to some exclusion rule e.g., maximal representation

  • seat remains open if within 3 months of the next general election, else:

    • special election

Let's roll with this. +1

dims commented 2 years ago

going dark for a minute ... https://github.com/cncf/memorials reminds us that life is short. Looks like or other loss of an elected steering committee member is enough to cover this case.

jberkus commented 2 years ago

2 down the stack feels arbitrary and doesn't account for the % of votes or skew between one or both of the next 2 and the 3-4 members seated from the election. If you took the top 4 and the skew between the 5th and the 4th is small but the skew between the 4/5th and the 6th is huge... it doesn't feel very representative of the community's will. It makes more sense to go down the stack so long as the candidates are within X% of the last seated candidate otherwise hold a special election.

I think these two are potentially sub-optimal outcomes: 1.2..3..4.5.................6 or 1..2.3.4..........5...........6

I share Kirsten's reservations here. It really depends on the election, and that's hard to incorporate into the rules. For example, last steering election we had 13 candidates, so it's reasonable to assume that anyone in the top 7 is fairly well "liked" by the contributors. BUT ... we've had one steering election where there were 5 candidates for 3 seats, and 2 down means picking the candidate who was the least preferred. If you combine that with the open nature of our elections -- where anyone can run, even if they have no prior association with Kubernetes -- it's a recipe for worry.

So I'd be more comfortable if using alternates from the prior election ended at 1. That is, the seat is offered to the next-most-preferred candidate. If they refuse it, we have a special election.

jberkus commented 2 years ago

That said, I'm fine merging this and having the Election Subproject recommend further revisions, later.

justaugustus commented 2 years ago

I share Kirsten's reservations here. It really depends on the election, and that's hard to incorporate into the rules. For example, last steering election we had 13 candidates, so it's reasonable to assume that anyone in the top 7 is fairly well "liked" by the contributors. BUT ... we've had one steering election where there were 5 candidates for 3 seats, and 2 down means picking the candidate who was the least preferred. If you combine that with the open nature of our elections -- where anyone can run, even if they have no prior association with Kubernetes -- it's a recipe for worry.

So I'd be more comfortable if using alternates from the prior election ended at 1. That is, the seat is offered to the next-most-preferred candidate. If they refuse it, we have a special election.

@jberkus -- I defer to your expertise as one of the most tenured election officials (for the project) on this discussion. Updated the language to reflect your suggestions in https://github.com/kubernetes/steering/pull/248/commits/107673f27720e863a7c2f0c460eafe3f98a7e2d6.

justaugustus commented 2 years ago

As this is getting close to a reasonable merge state, I've squashed the iterative commits and reflected the following changes in both the PR description and commit message:

Membership

Voting

Meetings

@kubernetes/steering-committee members --

As this PR was opened on 2022-06-29 at 2205 US EDT (11 days ago), I'd like to highlight two areas of our changes.md:

At any time prior to acceptance, a steering committee member may call a vote. A vote is scheduled no later than 4 weeks after initial introduction of the change. A vote may be scheduled earlier if all committee members agree.

AND

The change is accepted if three-fourths of the committee members vote in favor.

I would like to call a vote to accept these changes to the charter.

Please take a moment to review the PR in its current state.

In your review, please comment on:

  1. If you would be fine with voting on these changes ahead of the 4-week timeout period (this would need to be unanimous)
  2. If you are fine with voting early, please also signal that by voting with your /lgtm

If we are not unanimous in the decision to merge these changes ahead of the 4-week timeout period, we'll plan to vote on this on 2022-07-27 (as @dims mentioned in https://github.com/kubernetes/steering/pull/248#issuecomment-1176318852).

justaugustus commented 2 years ago

/assign @cblecker @dims @mrbobbytables @liggitt @parispittman @tpepper

In your review, please comment on:

1. If you would be fine with voting on these changes ahead of the 4-week timeout period (this would need to be unanimous)

I am fine with voting early (given I proposed it, but stating for the record).

2. If you are fine with voting early, please also signal that by voting with your `/lgtm`

LGTM (not using the slash command, since I am a co-author).

markjacksonfishing commented 2 years ago

Many hearts to everyone involved and thank you. From the bottom of my heart, thank you.

dims commented 2 years ago

This looks ready to ship now!

/approve /lgtm

k8s-ci-robot commented 2 years ago

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ahmed82, cpanato, dims, jdumars, parispittman, saschagrunert, sbueringer, vincepri

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: - ~~[OWNERS](https://github.com/kubernetes/steering/blob/main/OWNERS)~~ [dims,parispittman] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment
justaugustus commented 2 years ago

From https://groups.google.com/a/kubernetes.io/g/steering/c/JxZthc8HcXM/m/a8z01gd_BAAJ:

Kubernetes Community,

Thanks for the useful feedback regarding these proposed changes! As this charter update is close to a ready state (one outstanding review conversation), we'd like to allow a final opportunity for the community to provide feedback ahead of Steering review.

Timeline (all times are EOD US Eastern):

  • Wednesday, July 20th: closed for community feedback
  • Friday, July 22nd: Steering members review/provide feedback

As mentioned on the pull request, the four-week timeout period for changes concludes on Wednesday, July 27th. Steering members will plan to vote on inclusion of the proposed changes to the charter soon thereafter.

tpepper commented 2 years ago

I've been quiet the past weeks on this PR due to a family issue outside of the project pulling my attention away. Still I have been following the discussion, appreciate all of the ideation and concern folks have demonstrated toward getting this change right, and it's looking like a good update to my eyes.

liggitt commented 2 years ago

It's been 4 weeks since the initial introduction of this PR, so votes are due today.

I do think there should be a process to remove a steering member for cause, and I hoped the proposed process would be a good one, so I could support it.

I don't think the No confidence addition in this PR is a good process, for the following reasons:

  1. It gives no guidance and places no limits on when it may be used, which means it can be initiated for a bad reason, or no reason at all, as long as two steering members agree. The threshold to successfully remove a member is high, but even a failed attempt initiated for a bad reason can damage the reputation of the steering committee or the accused. Such an extreme step should have guardrails or guidance around it.

  2. It prioritizes the accusations in several ways, while giving the accused member no official way to participate, outside of generic community member feedback. It makes no attempt to place the accusations and response side-by-side for the community to see. As I expressed previously, this is important so the community can give well-informed feedback in the time provided, and not be biased by one perspective being given more prominence.

I think that adopting a biased process is worse than the process gap we have today, and will not serve the community well.

Because of that, I do not support this change, and vote no.

dims commented 2 years ago

After what seemed like an endless set of discussions (with recurring themes!!) excruciating process of drafting this PR in the public ... Many thanks to @parispittman and @justaugustus for leading us all to what we have today.

I vote yes.

cblecker commented 2 years ago

I think this is a needed update to our charter. In particular, I believe the section on "no confidence" is able to strike a fair balance as far as process, opportunity for consideration/feedback, and limiting potential harms to the community at large. As I've mentioned before, the invocation of this process would be an extreme circumstance for the community, but ultimately having these processes in place in order to maintain the continuity and functioning of the top level governing body is crucial.

I vote yes on this change.