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

lavalamp commented 2 years ago

(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.)

tpepper commented 2 years ago

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.

mrbobbytables commented 2 years ago

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.

parispittman commented 2 years ago

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

parispittman commented 2 years ago

6/7 votes yes on this change. /hold cancel