1. Cncf-Toc
  2. Messages

Expanded

Topics Messages Polls
   Date   
Re: Istio Steering Committee

alexis richardson
 

It isn't but it has aspects we can learn from (good and bad) as do other projects (eg apache kafka to name one).

This thread is specifically about steering committees, and what they can help with especially governance over direction.  And avoiding open core feature withholding. 

Istio just launched a Steering Committee and that's why it is relevant. 



On Tue, 25 Aug 2020, 20:00 Kris Nova, <kris.nova@...> wrote:
Excuse my ignorance here - but I thought Istio wasn't a CNCF project? Is there an official statement anywhere on where Istio landed? I am confused why I am seeing Istio threads like this if it's not a CNCF project? Or maybe it is? I honestly have no idea. 

On Tue, Aug 25, 2020 at 11:52 AM Josh Berkus <jberkus@...> wrote:
On 8/25/20 1:42 AM, alexis richardson wrote:
>
> Istio is highlighting some benefits of an SC model
>
> 1. Applies across whole 'broad' project not just repo level
> 2. Encourages diversity via non coding SC members, eg as Dan says you
> can also write .md files
> 3. Focus on overall direction on behalf of end users and community
> (avoiding the open core problems we see in other cases) 
>

The Istio SC is a serious political problem, and the project has ongoing
governance issues.  Why would we want to emulate this with CNCF projects?

An SC can be useful to a project that is large enough to warrant it, but
it isn't a cure for projects with problematic governance.  A project
with broken governance will just end up with a broken SC.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO






--
Kris Nova
Chief Open Source Advocate


85 2nd Street
San Francisco, CA 94105
Re: Istio Steering Committee

Kris Nova <kris.nova@...>
 

Excuse my ignorance here - but I thought Istio wasn't a CNCF project? Is there an official statement anywhere on where Istio landed? I am confused why I am seeing Istio threads like this if it's not a CNCF project? Or maybe it is? I honestly have no idea. 


On Tue, Aug 25, 2020 at 11:52 AM Josh Berkus <jberkus@...> wrote:
On 8/25/20 1:42 AM, alexis richardson wrote:
>
> Istio is highlighting some benefits of an SC model
>
> 1. Applies across whole 'broad' project not just repo level
> 2. Encourages diversity via non coding SC members, eg as Dan says you
> can also write .md files
> 3. Focus on overall direction on behalf of end users and community
> (avoiding the open core problems we see in other cases) 
>

The Istio SC is a serious political problem, and the project has ongoing
governance issues.  Why would we want to emulate this with CNCF projects?

An SC can be useful to a project that is large enough to warrant it, but
it isn't a cure for projects with problematic governance.  A project
with broken governance will just end up with a broken SC.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO






--
Kris Nova
Chief Open Source Advocate


85 2nd Street
San Francisco, CA 94105
Re: Istio Steering Committee

alexis richardson
 

Josh, feel free to highlight the negative aspects of Istio's history and governance on another thread.  I may well join you.  But please let's also give them credit for moving forward with improvements.  As i said in the email you quoted, their SC illustrates some of the positives.  I never said it is a panacea!


On Tue, 25 Aug 2020, 19:52 Josh Berkus, <jberkus@...> wrote:
On 8/25/20 1:42 AM, alexis richardson wrote:
>
> Istio is highlighting some benefits of an SC model
>
> 1. Applies across whole 'broad' project not just repo level
> 2. Encourages diversity via non coding SC members, eg as Dan says you
> can also write .md files
> 3. Focus on overall direction on behalf of end users and community
> (avoiding the open core problems we see in other cases) 
>

The Istio SC is a serious political problem, and the project has ongoing
governance issues.  Why would we want to emulate this with CNCF projects?

An SC can be useful to a project that is large enough to warrant it, but
it isn't a cure for projects with problematic governance.  A project
with broken governance will just end up with a broken SC.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO
Re: Istio Steering Committee

Josh Berkus
 

On 8/25/20 1:42 AM, alexis richardson wrote:

Istio is highlighting some benefits of an SC model

1. Applies across whole 'broad' project not just repo level
2. Encourages diversity via non coding SC members, eg as Dan says you
can also write .md files
3. Focus on overall direction on behalf of end users and community
(avoiding the open core problems we see in other cases) 
The Istio SC is a serious political problem, and the project has ongoing
governance issues. Why would we want to emulate this with CNCF projects?

An SC can be useful to a project that is large enough to warrant it, but
it isn't a cure for projects with problematic governance. A project
with broken governance will just end up with a broken SC.

--
--
Josh Berkus
Kubernetes Community
Red Hat OSPO
Re: [VOTE] Rook Graduation

Alena Prokharchyk
 

+1 binding

-alena.

On Jul 6, 2020, at 3:03 PM, Amye Scavarda Perrin <ascavarda@...> wrote:

Rook has applied for graduation (see https://github.com/cncf/toc/pull/366).

Saad Ali is the TOC sponsor for Rook, has completed DD and has called for a vote.  (https://lists.cncf.io/g/cncf-toc/message/4846)

Due diligence doc can be found here: https://docs.google.com/document/d/1acp9gJ1D_qflHKJBg4gB-nZwZQs87_Dh9uiH4pITc_U/edit?usp=sharing

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: Istio Steering Committee

Jaice Singer DuMars
 

I am glad to see the discussion started. I've done a lot of governance work on various projects and am happy to help in any way I can.

On Tue, Aug 25, 2020 at 9:08 AM alexis richardson <alexis@...> wrote:
Good points Matt.  Helm is well run and provides a useful model of one successful pattern.  

I don't think there is one true governance rule for who is on the SC.  IMHO it is critical to include non code maintainers, focus on people who have a real stake in success of projects and community, and avoid creating bureaucracy.  Asking maintainers "how could an SC help?" is a good starting point in regard to the latter point.



On Tue, 25 Aug 2020, 16:45 Matt Farina, <matt@...> wrote:
The Helm project has a similar model in its governance. There is a separation between Org Maintainers and Project Maintainers. The Org Maintainers are responsible for the project but not the technical decisions. The Project Maintainers own the code. The Helm Org Maintainers have restrictions that no one company/organization can have a majority of the members. That means you'll have at least 3 organizations represented. Currently, there are 7 companies represented.

One of the things that catches my attention about the Istio model is a matter of who decides which vendors to include. In the case of Istio it's Google. Who would even make these types of decisions for CNCF projects and have them work well for the people who maintain the code of those projects?

On Tue, Aug 25, 2020, at 11:11 AM, Jimmy Song wrote:
I think it's good for both vendors and end users.

On Aug 25, 2020, at 10:05 PM, Joe Beda <jbeda@...> wrote:

It is great to see a model that limits the influence of a single vendor.  The explicit split between coding and non-coding contributions is.. interesting.
 
One big difference worth calling out is the fact that the Istio model looks to have all credit for contributions accrue to companies, not individuals. This means that the community is defined by the vendors, not the contributors.  If someone leaves a job they, by definition, will have to give up their position on the SC (if I’m reading it correctly).
 
Looking at similar projects and different models (k8s) this will probably lead to a different quality of community vs. those that put people and project above vendors (“Community over product or company” is a k8s value).
 
Joe
 

From: cncf-toc@... <cncf-toc@...>
Date: Tuesday, August 25, 2020 at 1:43 AM
To: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: [cncf-toc] Istio Steering Committee

Hi TOC community 
 
I saw this news and wanted to highlight it.  With kubecon behind us and apparently summer too, perhaps we can revisit the Steering Committee thread.
 
 
Istio is highlighting some benefits of an SC model
 
1. Applies across whole 'broad' project not just repo level
2. Encourages diversity via non coding SC members, eg as Dan says you can also write .md files
3. Focus on overall direction on behalf of end users and community (avoiding the open core problems we see in other cases) 
 
I think we should arrange for a TOC session to discuss SCs. 
 
Alexis 
 
 
 
 
 
Re: Istio Steering Committee

alexis richardson
 

Good points Matt.  Helm is well run and provides a useful model of one successful pattern.  

I don't think there is one true governance rule for who is on the SC.  IMHO it is critical to include non code maintainers, focus on people who have a real stake in success of projects and community, and avoid creating bureaucracy.  Asking maintainers "how could an SC help?" is a good starting point in regard to the latter point.



On Tue, 25 Aug 2020, 16:45 Matt Farina, <matt@...> wrote:
The Helm project has a similar model in its governance. There is a separation between Org Maintainers and Project Maintainers. The Org Maintainers are responsible for the project but not the technical decisions. The Project Maintainers own the code. The Helm Org Maintainers have restrictions that no one company/organization can have a majority of the members. That means you'll have at least 3 organizations represented. Currently, there are 7 companies represented.

One of the things that catches my attention about the Istio model is a matter of who decides which vendors to include. In the case of Istio it's Google. Who would even make these types of decisions for CNCF projects and have them work well for the people who maintain the code of those projects?

On Tue, Aug 25, 2020, at 11:11 AM, Jimmy Song wrote:
I think it's good for both vendors and end users.

On Aug 25, 2020, at 10:05 PM, Joe Beda <jbeda@...> wrote:

It is great to see a model that limits the influence of a single vendor.  The explicit split between coding and non-coding contributions is.. interesting.
 
One big difference worth calling out is the fact that the Istio model looks to have all credit for contributions accrue to companies, not individuals. This means that the community is defined by the vendors, not the contributors.  If someone leaves a job they, by definition, will have to give up their position on the SC (if I’m reading it correctly).
 
Looking at similar projects and different models (k8s) this will probably lead to a different quality of community vs. those that put people and project above vendors (“Community over product or company” is a k8s value).
 
Joe
 

From: cncf-toc@... <cncf-toc@...>
Date: Tuesday, August 25, 2020 at 1:43 AM
To: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: [cncf-toc] Istio Steering Committee

Hi TOC community 
 
I saw this news and wanted to highlight it.  With kubecon behind us and apparently summer too, perhaps we can revisit the Steering Committee thread.
 
 
Istio is highlighting some benefits of an SC model
 
1. Applies across whole 'broad' project not just repo level
2. Encourages diversity via non coding SC members, eg as Dan says you can also write .md files
3. Focus on overall direction on behalf of end users and community (avoiding the open core problems we see in other cases) 
 
I think we should arrange for a TOC session to discuss SCs. 
 
Alexis 
 
 
 
 
 
Re: Istio Steering Committee

Matt Farina
 

The Helm project has a similar model in its governance. There is a separation between Org Maintainers and Project Maintainers. The Org Maintainers are responsible for the project but not the technical decisions. The Project Maintainers own the code. The Helm Org Maintainers have restrictions that no one company/organization can have a majority of the members. That means you'll have at least 3 organizations represented. Currently, there are 7 companies represented.

One of the things that catches my attention about the Istio model is a matter of who decides which vendors to include. In the case of Istio it's Google. Who would even make these types of decisions for CNCF projects and have them work well for the people who maintain the code of those projects?

On Tue, Aug 25, 2020, at 11:11 AM, Jimmy Song wrote:
I think it's good for both vendors and end users.

On Aug 25, 2020, at 10:05 PM, Joe Beda <jbeda@...> wrote:

It is great to see a model that limits the influence of a single vendor.  The explicit split between coding and non-coding contributions is.. interesting.
 
One big difference worth calling out is the fact that the Istio model looks to have all credit for contributions accrue to companies, not individuals. This means that the community is defined by the vendors, not the contributors.  If someone leaves a job they, by definition, will have to give up their position on the SC (if I’m reading it correctly).
 
Looking at similar projects and different models (k8s) this will probably lead to a different quality of community vs. those that put people and project above vendors (“Community over product or company” is a k8s value).
 
Joe
 

From: cncf-toc@... <cncf-toc@...>
Date: Tuesday, August 25, 2020 at 1:43 AM
To: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: [cncf-toc] Istio Steering Committee

Hi TOC community 
 
I saw this news and wanted to highlight it.  With kubecon behind us and apparently summer too, perhaps we can revisit the Steering Committee thread.
 
https://twitter.com/DanCiruli/status/1297945844767834112?s=09
 
Istio is highlighting some benefits of an SC model
 
1. Applies across whole 'broad' project not just repo level
2. Encourages diversity via non coding SC members, eg as Dan says you can also write .md files
3. Focus on overall direction on behalf of end users and community (avoiding the open core problems we see in other cases) 
 
I think we should arrange for a TOC session to discuss SCs. 
 
Alexis 
 
 
 
 
 
Re: Istio Steering Committee

Jimmy Song <jimmysong@...>
 

I think it's good for both vendors and end users.

On Aug 25, 2020, at 10:05 PM, Joe Beda <jbeda@...> wrote:

It is great to see a model that limits the influence of a single vendor.  The explicit split between coding and non-coding contributions is.. interesting.
 
One big difference worth calling out is the fact that the Istio model looks to have all credit for contributions accrue to companies, not individuals. This means that the community is defined by the vendors, not the contributors.  If someone leaves a job they, by definition, will have to give up their position on the SC (if I’m reading it correctly).
 
Looking at similar projects and different models (k8s) this will probably lead to a different quality of community vs. those that put people and project above vendors (“Community over product or company” is a k8s value).
 
Joe
 

From: cncf-toc@... <cncf-toc@...>
Date: Tuesday, August 25, 2020 at 1:43 AM
To: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: [cncf-toc] Istio Steering Committee

Hi TOC community 
 
I saw this news and wanted to highlight it.  With kubecon behind us and apparently summer too, perhaps we can revisit the Steering Committee thread.
 
 
Istio is highlighting some benefits of an SC model
 
1. Applies across whole 'broad' project not just repo level
2. Encourages diversity via non coding SC members, eg as Dan says you can also write .md files
3. Focus on overall direction on behalf of end users and community (avoiding the open core problems we see in other cases) 
 
I think we should arrange for a TOC session to discuss SCs. 
 
Alexis 
 
 
 
 
 
Re: Istio Steering Committee

alexis richardson
 

Good comments Joe. I also don't adore every aspect of the Istio
model. eg I agree that "credit for contributions accrue to companies,
not individuals" isn't optimal. But I still like what they are trying
to do overall.

On Tue, Aug 25, 2020 at 3:05 PM Joe Beda <jbeda@...> wrote:

It is great to see a model that limits the influence of a single vendor. The explicit split between coding and non-coding contributions is.. interesting.



One big difference worth calling out is the fact that the Istio model looks to have all credit for contributions accrue to companies, not individuals. This means that the community is defined by the vendors, not the contributors. If someone leaves a job they, by definition, will have to give up their position on the SC (if I’m reading it correctly).



Looking at similar projects and different models (k8s) this will probably lead to a different quality of community vs. those that put people and project above vendors (“Community over product or company” is a k8s value).



Joe



From: cncf-toc@... <cncf-toc@...>
Date: Tuesday, August 25, 2020 at 1:43 AM
To: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: [cncf-toc] Istio Steering Committee

Hi TOC community



I saw this news and wanted to highlight it. With kubecon behind us and apparently summer too, perhaps we can revisit the Steering Committee thread.



https://twitter.com/DanCiruli/status/1297945844767834112?s=09



Istio is highlighting some benefits of an SC model



1. Applies across whole 'broad' project not just repo level

2. Encourages diversity via non coding SC members, eg as Dan says you can also write .md files

3. Focus on overall direction on behalf of end users and community (avoiding the open core problems we see in other cases)



I think we should arrange for a TOC session to discuss SCs.



Alexis
Re: Istio Steering Committee

Joe Beda <jbeda@...>
 

It is great to see a model that limits the influence of a single vendor.  The explicit split between coding and non-coding contributions is.. interesting.

 

One big difference worth calling out is the fact that the Istio model looks to have all credit for contributions accrue to companies, not individuals. This means that the community is defined by the vendors, not the contributors.  If someone leaves a job they, by definition, will have to give up their position on the SC (if I’m reading it correctly).

 

Looking at similar projects and different models (k8s) this will probably lead to a different quality of community vs. those that put people and project above vendors (“Community over product or company” is a k8s value).

 

Joe

 

From: cncf-toc@... <cncf-toc@...>
Date: Tuesday, August 25, 2020 at 1:43 AM
To: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: [cncf-toc] Istio Steering Committee

Hi TOC community 

 

I saw this news and wanted to highlight it.  With kubecon behind us and apparently summer too, perhaps we can revisit the Steering Committee thread.

 

https://twitter.com/DanCiruli/status/1297945844767834112?s=09

 

Istio is highlighting some benefits of an SC model

 

1. Applies across whole 'broad' project not just repo level

2. Encourages diversity via non coding SC members, eg as Dan says you can also write .md files

3. Focus on overall direction on behalf of end users and community (avoiding the open core problems we see in other cases) 

 

I think we should arrange for a TOC session to discuss SCs. 

 

Alexis 

 

 

 

 

 
Re: Istio Steering Committee

Quinton Hoole <quinton@...>
 

Seems like a very good approach to me.

Q

On Tue, Aug 25, 2020, 01:43 alexis richardson <alexis@...> wrote:
Hi TOC community 

I saw this news and wanted to highlight it.  With kubecon behind us and apparently summer too, perhaps we can revisit the Steering Committee thread.

https://twitter.com/DanCiruli/status/1297945844767834112?s=09

Istio is highlighting some benefits of an SC model

1. Applies across whole 'broad' project not just repo level
2. Encourages diversity via non coding SC members, eg as Dan says you can also write .md files
3. Focus on overall direction on behalf of end users and community (avoiding the open core problems we see in other cases) 

I think we should arrange for a TOC session to discuss SCs. 

Alexis 
Istio Steering Committee

alexis richardson
 

Hi TOC community 

I saw this news and wanted to highlight it.  With kubecon behind us and apparently summer too, perhaps we can revisit the Steering Committee thread.

https://twitter.com/DanCiruli/status/1297945844767834112?s=09

Istio is highlighting some benefits of an SC model

1. Applies across whole 'broad' project not just repo level
2. Encourages diversity via non coding SC members, eg as Dan says you can also write .md files
3. Focus on overall direction on behalf of end users and community (avoiding the open core problems we see in other cases) 

I think we should arrange for a TOC session to discuss SCs. 

Alexis 
Re: [VOTE] TiKV Graduation

Li, Xiang
 

+1 binding

------------------------------------------------------------------
From:GolfenGuo <golfen.guo@...>
Sent At:2020 Aug. 21 (Fri.) 20:59
To:Amye Scavarda Perrin <ascavarda@...>
Cc:CNCF TOC <cncf-toc@...>
Subject:Re: [cncf-toc] [VOTE] TiKV Graduation

+1 NB

 

Thanks

--

郭峰  Golfen Guo

Shanghai DaoCloud Network Technology Co,. Ltd

#Your Cloud Native Application Delivered!#

 

发件人: <cncf-toc@...> 代表 "Alena Prokharchyk via lists.cncf.io" <aprokharchyk=apple.com@...>
答复: "aprokharchyk@..." <aprokharchyk@...>
日期: 2020年8月22日星期六上午8:14
收件人: Amye Scavarda Perrin <ascavarda@...>
抄送: CNCF TOC <cncf-toc@...>
主题: Re: [cncf-toc] [VOTE] TiKV Graduation

 

+1 binding.

 

-alena.



On Jul 6, 2020, at 3:05 PM, Amye Scavarda Perrin <ascavarda@...> wrote:

 

The TiKV project has applied for promotion to "Graduated" (see https://github.com/cncf/toc/pull/414).

Saad Ali is the TOC sponsor and has called for the vote at the end of the public comment period. (https://lists.cncf.io/g/cncf-toc/message/4847)

Due diligence doc can be found here: https://docs.google.com/document/d/1KCFeOdTIUXEkJJjaBrge8aIdovwdx4W2HngmUm5nfOA/edit#

CNCF SIG Storage has reviewed the proposal, their recommendation can be found here: https://docs.google.com/document/d/15TQERAYI-6NWj3eTGZxKJ_g3kBP9E11v1b-Gx8lFpt0/edit#

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

 

本邮件及附件含 DaoCloud 保密信息，仅限发送给上面地址中列出的个人或群组，禁止任何其他人以任何形式使用本邮件中的信息。若误收本邮件，请务必通知发送人并直接删去，不得使用、传播或复制本邮件。

Re: [VOTE] TiKV Graduation

GolfenGuo
 

+1 NB

 

Thanks

--

郭峰  Golfen Guo

Shanghai DaoCloud Network Technology Co,. Ltd

#Your Cloud Native Application Delivered!#

 

发件人: <cncf-toc@...> 代表 "Alena Prokharchyk via lists.cncf.io" <aprokharchyk=apple.com@...>
答复: "aprokharchyk@..." <aprokharchyk@...>
日期: 2020年8月22日 星期六 上午8:14
收件人: Amye Scavarda Perrin <ascavarda@...>
抄送: CNCF TOC <cncf-toc@...>
主题: Re: [cncf-toc] [VOTE] TiKV Graduation

 

+1 binding.

 

-alena.



On Jul 6, 2020, at 3:05 PM, Amye Scavarda Perrin <ascavarda@...> wrote:

 

The TiKV project has applied for promotion to "Graduated" (see https://github.com/cncf/toc/pull/414).

Saad Ali is the TOC sponsor and has called for the vote at the end of the public comment period. (https://lists.cncf.io/g/cncf-toc/message/4847)

Due diligence doc can be found here: https://docs.google.com/document/d/1KCFeOdTIUXEkJJjaBrge8aIdovwdx4W2HngmUm5nfOA/edit#

CNCF SIG Storage has reviewed the proposal, their recommendation can be found here: https://docs.google.com/document/d/15TQERAYI-6NWj3eTGZxKJ_g3kBP9E11v1b-Gx8lFpt0/edit#

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

 

本邮件及附件含 DaoCloud 保密信息，仅限发送给上面地址中列出的个人或群组，禁止任何其他人以任何形式使用本邮件中的信息。若误收本邮件，请务必通知发送人并直接删去，不得使用、传播或复制本邮件。

Re: [VOTE] TiKV Graduation

Saad Ali
 

+1 binding
Re: [VOTE] TiKV Graduation

Alena Prokharchyk
 

+1 binding.

-alena.

On Jul 6, 2020, at 3:05 PM, Amye Scavarda Perrin <ascavarda@...> wrote:

The TiKV project has applied for promotion to "Graduated" (see https://github.com/cncf/toc/pull/414).

Saad Ali is the TOC sponsor and has called for the vote at the end of the public comment period. (https://lists.cncf.io/g/cncf-toc/message/4847)

Due diligence doc can be found here: https://docs.google.com/document/d/1KCFeOdTIUXEkJJjaBrge8aIdovwdx4W2HngmUm5nfOA/edit#

CNCF SIG Storage has reviewed the proposal, their recommendation can be found here: https://docs.google.com/document/d/15TQERAYI-6NWj3eTGZxKJ_g3kBP9E11v1b-Gx8lFpt0/edit#

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] TiKV Graduation

Michelle Noorali <michelle.noorali@...>
 

+1 binding

On Wed, Aug 19, 2020 at 4:14 PM Sheng Liang via lists.cncf.io <sheng=rancher.com@...> wrote:

+1 binding

 

From: <cncf-toc@...> on behalf of "Kiran Mova via lists.cncf.io" <kiran.mova=mayadata.io@...>
Reply-To: "kiran.mova@..." <kiran.mova@...>
Date: Wednesday, August 19, 2020 at 8:47 AM
To: "justin.cormack@..." <justin.cormack@...>
Cc: Liz Rice <liz@...>, CNCF TOC <cncf-toc@...>, Amye Scavarda <ascavarda@...>
Subject: Re: [cncf-toc] [VOTE] TiKV Graduation

 

+1 NB on revote

--

Kiran Mova  | Co-Founder, Chief Architect MayaData  | kiran.mova@...

 

 

On Wed, Aug 19, 2020 at 5:06 PM Justin Cormack via lists.cncf.io <justin.cormack=docker.com@...> wrote:

+1 binding on the revote.

 

Justin

 

 

On Wed, Aug 19, 2020 at 9:50 AM Liz Rice <liz@...> wrote:

Not totally sure if this is still the right thread but anyway: 

 

+1 binding 

 

Thank you TiKV team for addressing the PD concern (and for everything else you are doing with the project!)

 

On Tue, 18 Aug 2020 at 02:38, <cfworking1990@...> wrote:

+1 NB
OpenTelemetry 2020 Annual Review

Constance Caramanolis <ccaramanolis@...>
 

Hello TOC,

 

OpenTelemetry’s annual review can be found here: https://github.com/cncf/toc/pull/515

 

Please let us know if you have any questions.

 

Thank you,

Constance
[RESULT] Cortex approved for incubation

Amye Scavarda Perrin
 

Cortex has been approved for incubation.(https://github.com/cncf/toc/pull/315)

8/11
Katie Gamanji: https://lists.cncf.io/g/cncf-toc/message/5035
Xiang Li: https://lists.cncf.io/g/cncf-toc/message/5052
Sheng Liang: https://lists.cncf.io/g/cncf-toc/message/5054
Justin Cormack: https://lists.cncf.io/g/cncf-toc/message/5057
Alena Prokharchyk: https://lists.cncf.io/g/cncf-toc/message/5069
Brendan Burns https://lists.cncf.io/g/cncf-toc/message/5167
Liz Rice: https://lists.cncf.io/g/cncf-toc/message/5171          
Michelle Noorali: https://lists.cncf.io/g/cncf-toc/message/5173

+1 NB
Ken Owens: https://lists.cncf.io/g/cncf-toc/message/5036
Richard Hartmann: https://lists.cncf.io/g/cncf-toc/message/5037
Matt Young: https://lists.cncf.io/g/cncf-toc/message/5038
Kiran Mova: https://lists.cncf.io/g/cncf-toc/message/5039
Ken Haines: https://lists.cncf.io/g/cncf-toc/message/5047
Vishal Raj: https://lists.cncf.io/g/cncf-toc/message/5048
Vineeth Reddy: https://lists.cncf.io/g/cncf-toc/message/5049
Ricardo P Katz: https://lists.cncf.io/g/cncf-toc/message/5051
Bartłomiej Płotka: https://lists.cncf.io/g/cncf-toc/message/5055
Martin Schneppenheim: https://lists.cncf.io/g/cncf-toc/message/5056
Peter Stibrany: https://lists.cncf.io/g/cncf-toc/message/5058
Lee Calcote: https://lists.cncf.io/g/cncf-toc/message/5064
Tom Wilkie: https://lists.cncf.io/g/cncf-toc/message/5065
King Chung Huang: https://lists.cncf.io/g/cncf-toc/message/5066
Marco Pracucci: https://lists.cncf.io/g/cncf-toc/message/5071
Alexis Richardson: https://lists.cncf.io/g/cncf-toc/message/5074
Ganesh Vernekar: https://lists.cncf.io/g/cncf-toc/message/5080

--
Amye Scavarda Perrin | Program Manager | amye@...
2801 - 2820 of 8023