charter: Add sections on membership, resignations, and removals #248
Conversation
k8s-ci-robot
added
cncf-cla: yes
k8s-ci-robot
added
the
approved
|
/hold for reviews |
k8s-ci-robot
added
the
do-not-merge/hold
|
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
force-pushed
the
charterchanges
branch
from
ded425a
to
f2cc7f8
Compare
|
(no-op push to fixup commit message.) |
There was a problem hiding this comment.
Couple observations:
-
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.
-
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.
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
/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. |
k8s-ci-robot
removed
the
lgtm
|
thanks for the update! |
k8s-ci-robot
added
the
lgtm
|
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: https://opensource.org/bylaws also has similar language: Please see links for full context of the snippets i pasted |
|
@parispittman and other steering folks, After talking to a friend and sleeping on it, i think it would be good to run a |
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).
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! |
|
/lgtm |
|
This looks ready to ship now! /approve |
k8s-ci-robot
added
the
lgtm
|
[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:
Approvers can indicate their approval by writing |
| of no confidence | ||
|
|
||
| The call for a vote of no confidence will happen in a public Steering Committee | ||
| meeting and must be documented as a GitHub issue in the committee's |
There was a problem hiding this comment.
To be symmetrical, we should explicitly allow the person targeted for removal to provide an explanation (rebuttal?) in the form an issue or a PR. That will stand out significantly more than a comment on an issue, persist better, and is symmetrical to the removal proposal.
There was a problem hiding this comment.
My personal opinion: no.
This isn't a trial or a debate. It's an up/down vote if the rest of the committee has confidence in the impacted individual to continue serving out their term.
I can assure you that the steering committee talks about everything going on with our community constantly, and the other members will be clear on the position of the person impacted.
This also doesn't restrict the impacted individual from speaking publicly, only that their statement isn't an official artifact of the process. We don't need to provide a platform.
There was a problem hiding this comment.
Something about that position bothers me, I'm not sure what. I'd propose stating that the party in question will be permitted to post (in a comment) a link to a defense/rebuttal on their own platform, and that moderation won't delete it. Since we can't really prevent people from writing such a document anyway.
We don't have to give people a platform, but it's very suspicious to attempt to deny them a platform, too.
There was a problem hiding this comment.
I'd propose stating that the party in question will be permitted to post (in a comment) a link to a defense/rebuttal on their own platform, and that moderation won't delete it.
I can't get behind this either, as it puts restrictions on our moderation and CoC teams.
What I'm worried about is someone using this process/platform to post a manifesto/screed in their defence. I sincerely hope that this wouldn't be the case, but I also hope that this is a policy we don't need to use in the first place.
If the impacted person posts a public comment that doesn't violate any moderation or CoC policies, then it can exist just like any other public comment on the issue. I'm not saying they shouldn't be able to do that. My concern is with elevating or somehow enshrining their "right" to do that as some sort of artifact of the process that cannot be touched.
There was a problem hiding this comment.
An unhinged screed is actually good evidence that removal is correct? I'm not saying we should host it, only that we do people a favor by helping them find it.
There was a problem hiding this comment.
My point is we can't make them take it down / fix it unless we own the forum.
I continue to think you all are overtraining on the possibility of a CoC violating response. I don't see how that would help the person in question at all.
There was a problem hiding this comment.
@lavalamp those responses rarely help anyone, but they're all too common (just look around at various Big Personalities that have existed in and around linux development communities for decades and the things they've said about queer people/women/disabled people/...).
There was a problem hiding this comment.
In general, sure, but as a response to an attempt to kick someone off a board? That would make very little sense as self defense. I'll change my mind given a few examples of such a thing, if you have them.
There was a problem hiding this comment.
@lavalamp no one here is going to take the bait and attempt to change your mind. That isn't positive nor productive. If this community is important enough to you, you are more than capable of researching the topic independently.
There was a problem hiding this comment.
That wasn't disingenuous, but you don't know me and I don't know how to prove that in a short amount of text. Nor do I know how to express the sentiment in a way that sufficiently distinguishes it from people who are attempting to drag out arguments rather than trying to find some objective reason to conclude them, which is how I meant it.
Anyway, it's too late now as people are voting.
k8s-ci-robot
removed
the
lgtm
justaugustus
force-pushed
the
charterchanges
branch
from
c4fbf35
to
53d8bf2
Compare
|
From https://groups.google.com/a/kubernetes.io/g/steering/c/JxZthc8HcXM/m/a8z01gd_BAAJ:
|
|
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. |
Charter updates including:
- Membership
- Define current composition of committee
- Elections
- Set upper bound of vacancies that may be filled via special election
- Clarify the only next most preferred candidate from previous election will
consider when filling vacancies
- Define resignation process
- Define process for removal via motion of no confidence
- Voting
- Clarify committee voting process
- Clarify numbers required to pass committee votes
- Add section for abstention
- Meetings
- Clarify quora for holding meetings and votes
Signed-off-by: Stephen Augustus <foo@auggie.dev>
Co-authored-by: Paris Pittman <paris_pittman@apple.com>
justaugustus
force-pushed
the
charterchanges
branch
from
53d8bf2
to
e2c68cb
Compare
|
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
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. |
|
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. |
|
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. |
|
(I obviously don't have a vote. Given the high bar for passing a no confidence vote, I think it would be OK to have one of the problems Jordan mentions, but still not both at the same time. Just because a process is intended to be used only in extreme situations, does not mean it'll actually be used like that. I ask the remaining committee members to seriously consider future boards unlike yourselves with different problems.) |
|
I have reviewed this PR content as it evolved to its current state and also the extensive discussion both on this PR and elsewhere. For a month now I’ve imagined and gamed out mentally past, present, and future scenarios impacting myself as well as past, present, and hypothetical future members. I’ve considered the state of art in similar processes in society, government, industry, religion, academia, open source generally, some specific open source projects, and in the Kubernetes project specifically. I see this as a pragmatic, sufficient change proposal relative to a gap in current governance documentation and also one that operationally is not overly prescriptive, in keeping with similar process philosophy in this project and in its current governance docs. For me the primary objections I see are quite parallel to the philosophical objections past and present toward having the instantiations we currently have for a Code of Conduct and for a Code of Conduct Committee. While not perfect to the eyes of all, those have proved functional and from my perspective have even proved generally successful, despite the potential risks present in their current forms. I have faith this change can also prove functional and successful. The risk factors are real but are pragmatically balanced in real life. And as with most things open source, all of this is subject to future patching to better refine if and when future context proves the need. I vote yes. |
There was a problem hiding this comment.
I want to thank everyone who thoughtfully contributed to this proposed charter change!
It gave us collectively quite a bit to reason about and we've tried to faithfully reflect most of the review feedback in the current text.
There's a beauty in the fact that so much of what we commit in open source is living, which means we/future versions of ourselves have the opportunity to continue to improve process over the lifetime of the project.
As a co-author, this may be implied, but to be explicit:
I vote yes to this change as it is currently proposed.
/lgtm
/approve
k8s-ci-robot
added
the
lgtm
|
This has been an incredibly long thread, and for what it's worth, I’m happy to see folks have such an interest in project governance. My own personal thoughts mirror that of @tpepper’s; he is just much more eloquent than I ever could be in writing a response. ;) The steering charter is a set of guiding principles, and while it has rarely been updated in the five years since it was first created, it is still a living document and is designed to evolve and improve with the community over time. I look forward to seeing where things go in the future; there is still more work to be done. I approve of the changes. |
|
+1 but reservations about including examples. why I'm in favor of this change was in the original body of the pull request - we need onboarding and off-boarding inside of the charter. it's that simple. I don't like where we went with the examples and hope to work on that post this merge. I was hoping the examples were used for discussion only and the text would get stronger as we went along. Examples should not be in a governance charter document. thanks to Stephen for helping this along while im on leave. |
|
6/7 votes yes on this change. |
k8s-ci-robot
removed
the
do-not-merge/hold
Charter updates including:
Membership
consider when filling vacancies
Voting
Meetings
(Content inspired by the language in the TOC charter. )
From @justaugustus in #248 (comment):
Votes
No
Yes