Perhaps we can separate out participation from acceptance?

I don’t feel comfortable with a community code of conduct not including the community, but also think many of us will acknowledge that some group of people need to be responsible for reviewing, accepting and merging changes.

I recommend treating it like any other open source project. Keep the code public in git, hold public reviews, and merge changes over time after discussing and general acceptance.

On Sun, Jun 12, 2022 at 10:48 AM Aeva <aeva.online@...> wrote:

+1 to the concerns which Stephen and Josh have articulated. There were several other folks attending the BoF in Valencia who have subject expertise and volunteered to help -- but who have been excluded by this framework.

I have been leading a lot of the work on the Kubernetes Code of Conduct Committee's evolution since 2019, and have continued to support up-leveling of policy changes even after my term ended. Particularly given the clarification to this election process, it is evident that I am being excluded from this WG -- even though it is chartered to continue my work. For context, I am both a Board Alternate and an Emeritus k8s CoCC member.

So. What is the goal of a representational Working Group that excludes the domain experts?

Regards,

--Aeva

On Sun, Jun 12, 2022 at 11:15 AM <celeste.e.horgan@...> wrote:

As this committee is currently structured, I do not feel that my participation in it would be productive.

Regards

Celeste Horgan