Date   

Re: OPA to graduation

Maor Goldberg <maor@...>
 

Hey,

Great news and congratulations to the OPA team, great project and a cornerstone for the cloud native enterprise. 

Looking at the maintainer status on the project, I wonder if there’s a plan to add more organizations?
I believe there’s only one organization (Styra) with maintainer status on the OPA project while Google and Microsoft only maintain the Gatekeeper project (my understanding is that Gatekeeper is a separate project). 

I think it will be great to see more than one organization sharing responsibility and leadership for this important project.

Good luck,
Maor. 

On Sep 16, 2020, at 10:46 AM, Brendan Burns via lists.cncf.io <bburns=microsoft.com@...> wrote:

Folks

The OPA project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)


The public comment period is now open for 2 weeks, and all SIGs, end users, TOC members, and community members are welcome to comment by replying to this thread.

Brendan Burns





Re: [RESULT] KubeEdge to move to Incubation

Tina Tsou
 

Congrats at KubeEdge Project!

Look forward to more deployment.


Thank you,
Tina ^ ^

On Sep 16, 2020, at 1:22 PM, Quinton Hoole via lists.cncf.io <quinton=hoole.biz@...> wrote:


Congrats KubeEdge!  Very well earned, IMO.

Q


On Wed, Sep 16, 2020 at 8:01 AM Amye Scavarda Perrin <ascavarda@...> wrote:
KubeEdge is approved to move to incubation: https://github.com/cncf/toc/pull/461

7/10
Alena Prokharchyk: https://lists.cncf.io/g/cncf-toc/message/5017
Brendan Burns: https://lists.cncf.io/g/cncf-toc/message/5030
Michelle Noorali: https://lists.cncf.io/g/cncf-toc/message/5043
Liz Rice: https://lists.cncf.io/g/cncf-toc/message/5050
Sheng Liang: https://lists.cncf.io/g/cncf-toc/message/5053
Justin Cormack: https://lists.cncf.io/g/cncf-toc/message/5067
Katie Gamanji: https://lists.cncf.io/g/cncf-toc/message/5249

+1 NB:
Davanum Srinivas: https://lists.cncf.io/g/cncf-toc/message/5018
Zhipeng Huang: https://lists.cncf.io/g/cncf-toc/message/5019
Felix: https://lists.cncf.io/g/cncf-toc/message/5020
Klaus Ma: https://lists.cncf.io/g/cncf-toc/message/5021
Roger Klorese: https://lists.cncf.io/g/cncf-toc/message/5022
Tina Tsou: https://lists.cncf.io/g/cncf-toc/message/5023
Andrew Aitken: https://lists.cncf.io/g/cncf-toc/message/5024
Ricardo Aravena: https://lists.cncf.io/g/cncf-toc/message/5025
Thor Anker Kvisgård Lange: https://lists.cncf.io/g/cncf-toc/message/5026
Kiran Mova: https://lists.cncf.io/g/cncf-toc/message/5027
Jeremy Rickard: https://lists.cncf.io/g/cncf-toc/message/5030
Dejan Bosanac: https://lists.cncf.io/g/cncf-toc/message/5032
Paul Buck: https://lists.cncf.io/g/cncf-toc/message/5033
Phillipe Robin: https://lists.cncf.io/g/cncf-toc/message/5040
Quinton Hoole: https://lists.cncf.io/g/cncf-toc/message/5041
Richard Hartmann: https://lists.cncf.io/g/cncf-toc/message/5042
Deepak Vij: https://lists.cncf.io/g/cncf-toc/message/5044
Kevin Ryan: https://lists.cncf.io/g/cncf-toc/message/5045
Anni Lai: https://lists.cncf.io/g/cncf-toc/message/5046
Steve Wong: https://lists.cncf.io/g/cncf-toc/message/5061
GolfenGuo: https://lists.cncf.io/g/cncf-toc/message/5070
Feilong Wang: https://lists.cncf.io/g/cncf-toc/message/5079
Qingchen Job: https://lists.cncf.io/g/cncf-toc/message/5131
Shenkh: https://lists.cncf.io/g/cncf-toc/message/5132
Ryan: https://lists.cncf.io/g/cncf-toc/message/5133
Plutoligs: https://lists.cncf.io/g/cncf-toc/message/5134
Zhiyiliu: https://lists.cncf.io/g/cncf-toc/message/5135
Stanley: https://lists.cncf.io/g/cncf-toc/message/5136
Zongkheshuaige: https://lists.cncf.io/g/cncf-toc/message/5137

--
Amye Scavarda Perrin | Program Manager | amye@...



--
Quinton Hoole
quinton@...
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: [RESULT] KubeEdge to move to Incubation

Quinton Hoole <quinton@...>
 

Congrats KubeEdge!  Very well earned, IMO.

Q


On Wed, Sep 16, 2020 at 8:01 AM Amye Scavarda Perrin <ascavarda@...> wrote:
KubeEdge is approved to move to incubation: https://github.com/cncf/toc/pull/461

7/10
Alena Prokharchyk: https://lists.cncf.io/g/cncf-toc/message/5017
Brendan Burns: https://lists.cncf.io/g/cncf-toc/message/5030
Michelle Noorali: https://lists.cncf.io/g/cncf-toc/message/5043
Liz Rice: https://lists.cncf.io/g/cncf-toc/message/5050
Sheng Liang: https://lists.cncf.io/g/cncf-toc/message/5053
Justin Cormack: https://lists.cncf.io/g/cncf-toc/message/5067
Katie Gamanji: https://lists.cncf.io/g/cncf-toc/message/5249

+1 NB:
Davanum Srinivas: https://lists.cncf.io/g/cncf-toc/message/5018
Zhipeng Huang: https://lists.cncf.io/g/cncf-toc/message/5019
Felix: https://lists.cncf.io/g/cncf-toc/message/5020
Klaus Ma: https://lists.cncf.io/g/cncf-toc/message/5021
Roger Klorese: https://lists.cncf.io/g/cncf-toc/message/5022
Tina Tsou: https://lists.cncf.io/g/cncf-toc/message/5023
Andrew Aitken: https://lists.cncf.io/g/cncf-toc/message/5024
Ricardo Aravena: https://lists.cncf.io/g/cncf-toc/message/5025
Thor Anker Kvisgård Lange: https://lists.cncf.io/g/cncf-toc/message/5026
Kiran Mova: https://lists.cncf.io/g/cncf-toc/message/5027
Jeremy Rickard: https://lists.cncf.io/g/cncf-toc/message/5030
Dejan Bosanac: https://lists.cncf.io/g/cncf-toc/message/5032
Paul Buck: https://lists.cncf.io/g/cncf-toc/message/5033
Phillipe Robin: https://lists.cncf.io/g/cncf-toc/message/5040
Quinton Hoole: https://lists.cncf.io/g/cncf-toc/message/5041
Richard Hartmann: https://lists.cncf.io/g/cncf-toc/message/5042
Deepak Vij: https://lists.cncf.io/g/cncf-toc/message/5044
Kevin Ryan: https://lists.cncf.io/g/cncf-toc/message/5045
Anni Lai: https://lists.cncf.io/g/cncf-toc/message/5046
Steve Wong: https://lists.cncf.io/g/cncf-toc/message/5061
GolfenGuo: https://lists.cncf.io/g/cncf-toc/message/5070
Feilong Wang: https://lists.cncf.io/g/cncf-toc/message/5079
Qingchen Job: https://lists.cncf.io/g/cncf-toc/message/5131
Shenkh: https://lists.cncf.io/g/cncf-toc/message/5132
Ryan: https://lists.cncf.io/g/cncf-toc/message/5133
Plutoligs: https://lists.cncf.io/g/cncf-toc/message/5134
Zhiyiliu: https://lists.cncf.io/g/cncf-toc/message/5135
Stanley: https://lists.cncf.io/g/cncf-toc/message/5136
Zongkheshuaige: https://lists.cncf.io/g/cncf-toc/message/5137

--
Amye Scavarda Perrin | Program Manager | amye@...



--
Quinton Hoole
quinton@...


Re: OPA to graduation

Quinton Hoole <quinton@...>
 

As some of you are probably aware, I've been a strong proponent of OPA for several years now.  Both the project, and the team seem like a great fit for CNCF graduation.

I have not yet read the full due diligence, but I can state that I am not aware of any fundamental blockers to graduation, and would love to see it proceed successfully.

(note: I have zero professional affiliations with the project - the above represent my best attempt at an unbiased opinion).

Q


 

On Wed, Sep 16, 2020 at 10:46 AM Brendan Burns via lists.cncf.io <bburns=microsoft.com@...> wrote:
Folks

The OPA project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)


The public comment period is now open for 2 weeks, and all SIGs, end users, TOC members, and community members are welcome to comment by replying to this thread.

Brendan Burns





--
Quinton Hoole
quinton@...


OPA to graduation

Brendan Burns
 

Folks

The OPA project has applied for graduation from incubation to graduated. (https://github.com/cncf/toc/pull/520)


The public comment period is now open for 2 weeks, and all SIGs, end users, TOC members, and community members are welcome to comment by replying to this thread.

Brendan Burns




[RESULT] KubeEdge to move to Incubation

Amye Scavarda Perrin
 

KubeEdge is approved to move to incubation: https://github.com/cncf/toc/pull/461

7/10
Alena Prokharchyk: https://lists.cncf.io/g/cncf-toc/message/5017
Brendan Burns: https://lists.cncf.io/g/cncf-toc/message/5030
Michelle Noorali: https://lists.cncf.io/g/cncf-toc/message/5043
Liz Rice: https://lists.cncf.io/g/cncf-toc/message/5050
Sheng Liang: https://lists.cncf.io/g/cncf-toc/message/5053
Justin Cormack: https://lists.cncf.io/g/cncf-toc/message/5067
Katie Gamanji: https://lists.cncf.io/g/cncf-toc/message/5249

+1 NB:
Davanum Srinivas: https://lists.cncf.io/g/cncf-toc/message/5018
Zhipeng Huang: https://lists.cncf.io/g/cncf-toc/message/5019
Felix: https://lists.cncf.io/g/cncf-toc/message/5020
Klaus Ma: https://lists.cncf.io/g/cncf-toc/message/5021
Roger Klorese: https://lists.cncf.io/g/cncf-toc/message/5022
Tina Tsou: https://lists.cncf.io/g/cncf-toc/message/5023
Andrew Aitken: https://lists.cncf.io/g/cncf-toc/message/5024
Ricardo Aravena: https://lists.cncf.io/g/cncf-toc/message/5025
Thor Anker Kvisgård Lange: https://lists.cncf.io/g/cncf-toc/message/5026
Kiran Mova: https://lists.cncf.io/g/cncf-toc/message/5027
Jeremy Rickard: https://lists.cncf.io/g/cncf-toc/message/5030
Dejan Bosanac: https://lists.cncf.io/g/cncf-toc/message/5032
Paul Buck: https://lists.cncf.io/g/cncf-toc/message/5033
Phillipe Robin: https://lists.cncf.io/g/cncf-toc/message/5040
Quinton Hoole: https://lists.cncf.io/g/cncf-toc/message/5041
Richard Hartmann: https://lists.cncf.io/g/cncf-toc/message/5042
Deepak Vij: https://lists.cncf.io/g/cncf-toc/message/5044
Kevin Ryan: https://lists.cncf.io/g/cncf-toc/message/5045
Anni Lai: https://lists.cncf.io/g/cncf-toc/message/5046
Steve Wong: https://lists.cncf.io/g/cncf-toc/message/5061
GolfenGuo: https://lists.cncf.io/g/cncf-toc/message/5070
Feilong Wang: https://lists.cncf.io/g/cncf-toc/message/5079
Qingchen Job: https://lists.cncf.io/g/cncf-toc/message/5131
Shenkh: https://lists.cncf.io/g/cncf-toc/message/5132
Ryan: https://lists.cncf.io/g/cncf-toc/message/5133
Plutoligs: https://lists.cncf.io/g/cncf-toc/message/5134
Zhiyiliu: https://lists.cncf.io/g/cncf-toc/message/5135
Stanley: https://lists.cncf.io/g/cncf-toc/message/5136
Zongkheshuaige: https://lists.cncf.io/g/cncf-toc/message/5137

--
Amye Scavarda Perrin | Program Manager | amye@...


Agenda for 9/15

Amye Scavarda Perrin
 

Hi all, 
We'll be meeting tomorrow with a presentation on the latest End User Tech Radar.


Re: [RESULT] Tech Lead nomination for SIG Observability: Bartłomiej Płotka

Bartłomiej Płotka
 

Thanks, Amye for the summary, and thank you All for your trust! (: 

Looking forward to what we can achieve together in the CNCF Observability space 💪

Kind Regards,
Bartek Płotka (@bwplotka)



Re: Sandbox Projects included from September 8 TOC meeting

Li, Xiang
 

(I am familiar with the team behind the project, and the background of the project).

OpenKurise itself is not an experiment. It supports some of the largest Kubernetes clusters in production environment at Alibaba and a few other large internet companies (https://github.com/openkruise/kruise/issues/289).

For any sizable companies using Kubeternetes, it is not uncommon to have tens of generic controllers that are not specific to any particular application. 

The motivation of OpenKruise project is to find a subset of these controllers that are commonly useful to a number of users rather than just one company. So we can reduce some duplication, improve collaboration and help the community to grow.

Yes, if some enhancements or workload types are popular enough that everyone wants then, we hope them to be upstreamed to Kubernetes project itself.

------------------------------------------------------------------
From:Liz Rice <liz@...>
Sent At:2020 Sep. 9 (Wed.) 10:39
To:Matt Farina <matt@...>
Cc:CNCF TOC <cncf-toc@...>
Subject:Re: [cncf-toc] Sandbox Projects included from September 8 TOC meeting

OpenKruise is experimenting with a number of workload-related resource definitions, some of which are enhancements to existing core K8s resources. We're happy to see these experiments and want to support them, but we wondered if it makes more sense for them to belong within the purview of the Kubernetes project rather than as a standalone project? My understanding is that OpenKruise intends to eventually contribute successful experiments to upstream Kubernetes anyway. 

There's also a question about project scope. If the Kubernetes project would actually prefer these experiments to take place in a separate project, does that make OpenKruise the natural home for all workload-related CRD ideas, or some other scope? 

The discussion was recorded (I'm sure Amy can provide the link if she hasn't already circulated it) and that might be worth listening to for more context, if you have the time.   


On Wed, Sep 9, 2020 at 4:21 PM Matt Farina <matt@...> wrote:
OpenKruise has reached out to Kubernetes SIG Apps and we will discuss the project.

For context, why would the TOC suggest OpenKruise fall under k8s instead of being it's own CNCF sandbox project?

On Tue, Sep 8, 2020, at 4:05 PM, Amye Scavarda Perrin wrote:
The TOC has reviewed the current Sandbox projects applying for inclusion. 

The projects included are: 
Backstage 
Tremor
metal3-io
Porter
OpenYurt 
Open Service Mesh 

Other projects not brought to vote: 
checkov - further conversation needed re: roadmap, holding for updated roadmap
protop - no roadmap! https://github.com/protop-io/protop#roadmap Should this be a subproject of gRPC? TOC would like feedback from the gRPC project. 
Dataset Lifecycle Framework - next steps: TOC conversation with SIG Storage, Kubernetes COSI KEP
OpenKruise - discussion with Kubernetes Steering Committee needed, SIG Apps - should this be a subproject?
Predator - no clear roadmap, resubmit with clearer roadmap
SchemaHero - no clear roadmap, resubmit with clearer roadmap
Keylime - scheduled for next closed meeting, September 22

As part of this process, we've now added a new question to the sandbox proposal form: "Why do you want to contribute your project to the CNCF? What would you like to get out of being part of the CNCF?" 

Welcome to these new sandbox projects! 
--
Amye Scavarda Perrin | Program Manager | amye@...


Re: Sandbox Projects included from September 8 TOC meeting

Amye Scavarda Perrin
 

The recording for the 9/8 meeting is up on YouTube: https://www.youtube.com/watch?v=q_FO3PWnkY4 


On Wed, Sep 9, 2020 at 10:36 AM Liz Rice <liz@...> wrote:
OpenKruise is experimenting with a number of workload-related resource definitions, some of which are enhancements to existing core K8s resources. We're happy to see these experiments and want to support them, but we wondered if it makes more sense for them to belong within the purview of the Kubernetes project rather than as a standalone project? My understanding is that OpenKruise intends to eventually contribute successful experiments to upstream Kubernetes anyway. 

There's also a question about project scope. If the Kubernetes project would actually prefer these experiments to take place in a separate project, does that make OpenKruise the natural home for all workload-related CRD ideas, or some other scope? 

The discussion was recorded (I'm sure Amy can provide the link if she hasn't already circulated it) and that might be worth listening to for more context, if you have the time.   


On Wed, Sep 9, 2020 at 4:21 PM Matt Farina <matt@...> wrote:
OpenKruise has reached out to Kubernetes SIG Apps and we will discuss the project.

For context, why would the TOC suggest OpenKruise fall under k8s instead of being it's own CNCF sandbox project?

On Tue, Sep 8, 2020, at 4:05 PM, Amye Scavarda Perrin wrote:
The TOC has reviewed the current Sandbox projects applying for inclusion. 

The projects included are: 
Backstage 
Tremor
metal3-io
Porter
OpenYurt 
Open Service Mesh 

Other projects not brought to vote: 
checkov - further conversation needed re: roadmap, holding for updated roadmap
protop - no roadmap! https://github.com/protop-io/protop#roadmap Should this be a subproject of gRPC? TOC would like feedback from the gRPC project. 
Dataset Lifecycle Framework - next steps: TOC conversation with SIG Storage, Kubernetes COSI KEP
OpenKruise - discussion with Kubernetes Steering Committee needed, SIG Apps - should this be a subproject?
Predator - no clear roadmap, resubmit with clearer roadmap
SchemaHero - no clear roadmap, resubmit with clearer roadmap
Keylime - scheduled for next closed meeting, September 22

As part of this process, we've now added a new question to the sandbox proposal form: "Why do you want to contribute your project to the CNCF? What would you like to get out of being part of the CNCF?" 

Welcome to these new sandbox projects! 
--
Amye Scavarda Perrin | Program Manager | amye@...



--
Amye Scavarda Perrin | Program Manager | amye@...


Re: Sandbox Projects included from September 8 TOC meeting

Liz Rice
 

OpenKruise is experimenting with a number of workload-related resource definitions, some of which are enhancements to existing core K8s resources. We're happy to see these experiments and want to support them, but we wondered if it makes more sense for them to belong within the purview of the Kubernetes project rather than as a standalone project? My understanding is that OpenKruise intends to eventually contribute successful experiments to upstream Kubernetes anyway. 

There's also a question about project scope. If the Kubernetes project would actually prefer these experiments to take place in a separate project, does that make OpenKruise the natural home for all workload-related CRD ideas, or some other scope? 

The discussion was recorded (I'm sure Amy can provide the link if she hasn't already circulated it) and that might be worth listening to for more context, if you have the time.   


On Wed, Sep 9, 2020 at 4:21 PM Matt Farina <matt@...> wrote:
OpenKruise has reached out to Kubernetes SIG Apps and we will discuss the project.

For context, why would the TOC suggest OpenKruise fall under k8s instead of being it's own CNCF sandbox project?

On Tue, Sep 8, 2020, at 4:05 PM, Amye Scavarda Perrin wrote:
The TOC has reviewed the current Sandbox projects applying for inclusion. 

The projects included are: 
Backstage 
Tremor
metal3-io
Porter
OpenYurt 
Open Service Mesh 

Other projects not brought to vote: 
checkov - further conversation needed re: roadmap, holding for updated roadmap
protop - no roadmap! https://github.com/protop-io/protop#roadmap Should this be a subproject of gRPC? TOC would like feedback from the gRPC project. 
Dataset Lifecycle Framework - next steps: TOC conversation with SIG Storage, Kubernetes COSI KEP
OpenKruise - discussion with Kubernetes Steering Committee needed, SIG Apps - should this be a subproject?
Predator - no clear roadmap, resubmit with clearer roadmap
SchemaHero - no clear roadmap, resubmit with clearer roadmap
Keylime - scheduled for next closed meeting, September 22

As part of this process, we've now added a new question to the sandbox proposal form: "Why do you want to contribute your project to the CNCF? What would you like to get out of being part of the CNCF?" 

Welcome to these new sandbox projects! 
--
Amye Scavarda Perrin | Program Manager | amye@...


Re: Sandbox Projects included from September 8 TOC meeting

Matt Farina
 

OpenKruise has reached out to Kubernetes SIG Apps and we will discuss the project.

For context, why would the TOC suggest OpenKruise fall under k8s instead of being it's own CNCF sandbox project?

On Tue, Sep 8, 2020, at 4:05 PM, Amye Scavarda Perrin wrote:
The TOC has reviewed the current Sandbox projects applying for inclusion. 

The projects included are: 
Backstage 
Tremor
metal3-io
Porter
OpenYurt 
Open Service Mesh 

Other projects not brought to vote: 
checkov - further conversation needed re: roadmap, holding for updated roadmap
protop - no roadmap! https://github.com/protop-io/protop#roadmap Should this be a subproject of gRPC? TOC would like feedback from the gRPC project. 
Dataset Lifecycle Framework - next steps: TOC conversation with SIG Storage, Kubernetes COSI KEP
OpenKruise - discussion with Kubernetes Steering Committee needed, SIG Apps - should this be a subproject?
Predator - no clear roadmap, resubmit with clearer roadmap
SchemaHero - no clear roadmap, resubmit with clearer roadmap
Keylime - scheduled for next closed meeting, September 22

As part of this process, we've now added a new question to the sandbox proposal form: "Why do you want to contribute your project to the CNCF? What would you like to get out of being part of the CNCF?" 

Welcome to these new sandbox projects! 
--
Amye Scavarda Perrin | Program Manager | amye@...


Sandbox Projects included from September 8 TOC meeting

Amye Scavarda Perrin
 

The TOC has reviewed the current Sandbox projects applying for inclusion. 

The projects included are: 
Backstage 
Tremor
metal3-io
Porter
OpenYurt 
Open Service Mesh 

Other projects not brought to vote: 
checkov - further conversation needed re: roadmap, holding for updated roadmap
protop - no roadmap! https://github.com/protop-io/protop#roadmap Should this be a subproject of gRPC? TOC would like feedback from the gRPC project. 
Dataset Lifecycle Framework - next steps: TOC conversation with SIG Storage, Kubernetes COSI KEP
OpenKruise - discussion with Kubernetes Steering Committee needed, SIG Apps - should this be a subproject?
Predator - no clear roadmap, resubmit with clearer roadmap
SchemaHero - no clear roadmap, resubmit with clearer roadmap
Keylime - scheduled for next closed meeting, September 22

As part of this process, we've now added a new question to the sandbox proposal form: "Why do you want to contribute your project to the CNCF? What would you like to get out of being part of the CNCF?" 

Welcome to these new sandbox projects! 
--
Amye Scavarda Perrin | Program Manager | amye@...


[RESULT] Tech Lead nomination for SIG Observability: Bartłomiej Płotka

Amye Scavarda Perrin
 


Re: [EXTERNAL] Re: [cncf-toc] [VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka

Li, Xiang
 

+1 binding

------------------------------------------------------------------
From:Nayak, Mahesh Manjunath (Nokia - US/Mountain View) <mahesh_manjunath.nayak@...>
Sent At:2020 Aug. 13 (Thu.) 10:07
To:bburns@... <bburns@...>; Quinton Hoole <quinton@...>; michelle.noorali@... <michelle.noorali@...>
Cc:Amye Scavarda Perrin <ascavarda@...>; CNCF TOC <cncf-toc@...>
Subject:Re: [EXTERNAL] Re: [cncf-toc] [VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka

+1, binding.

 

From: cncf-toc@... <cncf-toc@...> On Behalf Of Brendan Burns via lists.cncf.io
Sent: Thursday, August 13, 2020 10:02 AM
To: Quinton Hoole <quinton@...>; michelle.noorali@...
Cc: Amye Scavarda Perrin <ascavarda@...>; CNCF TOC <cncf-toc@...>
Subject: Re: [EXTERNAL] Re: [cncf-toc] [VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka

 

+1, binding.

 

 


From: cncf-toc@... <cncf-toc@...> on behalf of Michelle Noorali via lists.cncf.io <michelle.noorali=gmail.com@...>
Sent: Tuesday, August 11, 2020 8:20 AM
To: Quinton Hoole <quinton@...>
Cc: Amye Scavarda Perrin <ascavarda@...>; CNCF TOC <cncf-toc@...>
Subject: [EXTERNAL] Re: [cncf-toc] [VOTE] Tech Lead nomination for SIG Observability: Bartłomiej Płotka

 

+1 binding

 

On Sun, Aug 9, 2020 at 1:13 PM Quinton Hoole <quinton@...> wrote:

+100 NB.  Great!

 

Q

 

On Thu, Jul 9, 2020, 15:45 Amye Scavarda Perrin <ascavarda@...> wrote:

Matt Young and Richard Hartman of SIG Observability have nominated Bartłomiej Płotka as Tech Lead.

https://lists.cncf.io/g/cncf-toc/message/4592

 

Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

 

--

Amye Scavarda Perrin | Program Manager | amye@...


Re: [VOTE] Rook Graduation

Queeny Jin
 

+1 NB.


Re: Istio Steering Committee

Josh Berkus
 

On 9/2/20 2:49 PM, Matt Wilson wrote:
I think this is an interesting conversation, but it doesn't
necessarily get closer to resolving https://github.com/cncf/toc/issues/459.
Yeah, I would love to see more of the other discussion on the gov-wg ML.
Pick it up there?

I would like to make a suggestion: none of what I have seen proposed
can _guarantee_ that "the project is open to contributions regardless
of employer" as was summarized as the objective in
https://github.com/cncf/toc/issues/459#issuecomment-641550257.

It seems that what is being asking for is evidence, or perhaps
"proof", as embodied a project's documentation (as proposed with the
SC concept) or commit history (as it currently stands in the
graduation criteria), that they are open to contributions from
all. What matters far more to _me_ is what happens in cases where a
project is faced with disagreements, and how they are resolved
constructively and collaboratively. And it may be that a community has
never faced any material disagreement.
The "proof" is where it is. If there are people who are allowed to
merge code/docs for the project and work for multiple organizations,
that's probably the strongest proof we can obtain that contributions are
not limited by employer.

It is definitely true that there are other possible demonstrations of
openness to contributions. That's why I asked the TOC to rule on a
rationale; by making the *reason* paramout, SIGS/TOC are a position to
judge borderline cases. And if open source is good for anything, it's
creating borderline cases.

Rather than focusing on various tests and studying past events, I
would rather see the TOC and (only in the very rarest of
circumstances) GB be able to act as an ombudsman for those rare
significant disagreements that reach an impasse, because each
circumstance of disagreement is going to be unique and can require a
collection of facts before judgment.
...not quite sure what you're saying here, in practical terms.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO


Re: Istio Steering Committee

Matt Wilson
 

On Wed, Sep 2, 2020 at 09:22 AM, Josh Berkus wrote:

On 9/1/20 1:58 PM, Matt Wilson wrote:
Perhaps you are suggesting is that end-users having a *binding vote*
in a fixed-Seat governing body, where formal voting happens most often
by convening the holders of those seats at an appointed time, at
which having 60% of the Seats shall constitute a quorum?
This can actually be a great structure for a project with a small number
of vendors doing most of the technical work, but larger number of
users. The difficulty is recruiting users with a sufficient depth of
technical knowledge to have meaningful input, e.g. if the end-user SC
members don't really understand the API, they're not gonna spot a
breaking change.
I'm not personally aware of a good example of a strict quorum voting
structure that provided an empowering voice or an ability for people
who are not technically as deep. But I am definitely curious to learn
more about effective practices put in place by communities, keeping in
mind that effective practices for one group of humans may differ for
another. Is there one I should study more closely?

The other problem is avoiding "captive" users. If a project's
leadership group contains only the staff of one vendor, and that
vendor's commercial users, then it's still a single-company project.
You'd need to have at least a few "freeware" users in there to mix
things up.
This is one of the areas where I continue to struggle to understand
the concern. To me, open-source licenses make it difficult to hold
users/adopters "captive." When vendors make an attempt to do so, it
can result in others stepping up to create better, more "open"
conditions. Sometimes (historically, rarely) that means starting a new
community, since that is something that open-source licenses enable.

The voices of "freeware" users is an important and valuable. When it
comes to how a vendor invests their time, I think that paying
attention to paying customers is a natural thing to do. Paying
attention to non-paying customers can be a very important part of your
business, especially in growing your business. I do not think that a
vendor has an obligation to provide free services or development for
"freeware" users. Also, I do not think that there needs to be some
structural element to open-source governance recommendations, to
"ensure" that a project is being "open enough."

I think this is an interesting conversation, but it doesn't
necessarily get closer to resolving https://github.com/cncf/toc/issues/459.

I would like to make a suggestion: none of what I have seen proposed
can _guarantee_ that "the project is open to contributions regardless
of employer" as was summarized as the objective in
https://github.com/cncf/toc/issues/459#issuecomment-641550257.

It seems that what is being asking for is evidence, or perhaps
"proof", as embodied a project's documentation (as proposed with the
SC concept) or commit history (as it currently stands in the
graduation criteria), that they are open to contributions from
all. What matters far more to _me_ is what happens in cases where a
project is faced with disagreements, and how they are resolved
constructively and collaboratively. And it may be that a community has
never faced any material disagreement.

Rather than focusing on various tests and studying past events, I
would rather see the TOC and (only in the very rarest of
circumstances) GB be able to act as an ombudsman for those rare
significant disagreements that reach an impasse, because each
circumstance of disagreement is going to be unique and can require a
collection of facts before judgment.

--msw


Re: Istio Steering Committee

Josh Berkus
 

On 9/1/20 1:58 PM, Matt Wilson wrote:
Perhaps you are suggesting is that end-users having a *binding vote*
in a fixed-Seat governing body, where formal voting happens most often
by convening the holders of those seats at an appointed time, at
which having 60% of the Seats shall constitute a quorum?
This can actually be a great structure for a project with a small number
of vendors doing most of the technical work, but larger number of
users. The difficulty is recruiting users with a sufficient depth of
technical knowledge to have meaningful input, e.g. if the end-user SC
members don't really understand the API, they're not gonna spot a
breaking change.

The other problem is avoiding "captive" users. If a project's
leadership group contains only the staff of one vendor, and that
vendor's commercial users, then it's still a single-company project.
You'd need to have at least a few "freeware" users in there to mix
things up.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO


[RESULT] TiKV Approved for Graduation

Amye Scavarda Perrin
 

2041 - 2060 of 7321