Re: [cncf-gb] Formation of CNCF CoC Update Working Group


Stephen Augustus (augustus)
 

+1.

 

If we’re saying that one of the goals is to ensure a minimum participation bound from each of these representative groups, I would maybe suggest:

  • Allow the representative group to determine how they will satisfy it e.g., several GB alternates are subject matter experts (read: I disagree w/ enforcing that this needs to be a primary GB rep)
  • (Loosely) assist (but not enforce) what the expectations for these representatives are around the feedback loop between this WG and their group

 

On the other clarifications to eligibility…

 

TAG reps

 

From the ContribStrat charter:

This charter describes the operations of the CNCF Technical Advisory Group (TAG) Contributor Strategy. This TAG is responsible for contributor experience, sustainability, governance, and openness guidance to help CNCF community groups and projects with their own contributor strategies for a healthy project.

 

I mention that to say, it could be useful to instead suggest a minimal representative group from all TAGs, and ask TAG ContribStrat to provide guidance/help coordinate with other TAGs who that group might be.

 

Kubernetes CoC Committee

 

Most of the emeritus members of K8s CoCC are still involved in some way/shape/form with the CNCF community.

I’m not sure I understand the value in restricting to active members, especially given the thoughtfulness and precision that is required to effectively serve on that committee for the Kubernetes community.

 

Again, I feel this is a selection that can and should be deferred to the group.

 

Finally, given that:

Updates to the Code of Conduct must be approved by the TOC (CNCF Charter §13), but creation of a CoC Committee to handle CoC incident response & resolution must be approved by the Governing Board (CNCF Charter §5(d)(vii))

 

I see no need for the co-chairs of this WG to be representatives of the GB and the TOC.

The outcomes of these discussions will naturally route to these bodies as resolutions/proposals.

 

Delegate the responsibility to the representative groups to select their delegates.

Then have those delegates select their co-chairs.

 

Precedence examples:

  • GB chairperson selection
  • TOC chairperson selection
  • K8s Steering GB rep selection

 

---


Stephen Augustus (he/him)

Head of Open Source

augustus@...

 

Open Source Program Office questions? Reach us at ospo@....

 

My working hours may not be your working hours.
Please do not feel obligated to reply outside of your normal work schedule.

 

On 6/9/22, 15:00, "cncf-toc@..." <cncf-toc@...> wrote:

On 09/06/22 11:29 -0700, Josh Berkus wrote:

>On 6/9/22 03:28, Davanum Srinivas wrote:

>> 

>>most of the bodies, you can see that we are asking to send 1 or 2

>>people who essentially will help the WG interface with the body. We

>>ended up this way because of the unbounded group of maintainers (we

>>don't know how many of them will actually show up! and we wanted to

>>keep the WG of a manageable size). Of course as we get it started

>>the WG chairs (one from TOC and one from WG, which may not be

>>Arun/me) and the WG can figure out how best to do their work once

>>they are constituted (depending on who shows up and how many of

>>them!).

>That was what I assumed when each group was asked to appoint someone.

>In TAG-CS, we were already discussing who we would nominate.

>However, TAG chairs and core maintainers are the most overcommitted

>people we have in the ecosystem.  If this WG is going to be successful

>in designing a new CoCC system for a very complicated situation, it

>can't be primarily made up of people who are already oversubscribed.

>Beyond that, we had an excellent discussion and intro session at

>KubeCon with Joanna Lee. That session led attendees to expect that

>they would be invited to participate further in CoC process

>discussions in the CNCF. Most of the attendees in that session would

>be excluded from participation under this criteria.

>I guess what I'm getting at is: why is this a closed group with

>membership restrictions? That's not how we run any of our TAGs.  

>What's the reason to not make the group open to any committed

>community member who's willing to do the hard work required?

>--

>-- Josh Berkus

>   Kubernetes Community Architect

>   OSPO, OCTO

 

+1

 

 

 

 

 

Join {cncf-toc@lists.cncf.io to automatically receive all group messages.