Date   

Re: [RESULT] SIG Observability Approved

Richard Hartmann
 

Yay!

On Mon, Apr 6, 2020 at 9:22 PM Amye Scavarda Perrin
<ascavarda@...> wrote:

Brendan Burns has called for a vote on SIG Observability: https://github.com/cncf/sig-observability/pull/1
Welcome new SIG!

+1 Binding: 8/10
Brendan Burns: https://lists.cncf.io/g/cncf-toc/message/4471
Sheng Liang: https://lists.cncf.io/g/cncf-toc/message/4493
Justin Cormack: https://lists.cncf.io/g/cncf-toc/message/4473
Matt Klein: https://lists.cncf.io/g/cncf-toc/message/4474
Alena Prokharchyk: https://lists.cncf.io/g/cncf-toc/message/4480
Liz Rice: https://lists.cncf.io/g/cncf-toc/message/4482
Katie Gamanji: https://lists.cncf.io/g/cncf-toc/message/4488
Michelle Noorali: https://lists.cncf.io/g/cncf-toc/message/4506

+1 NB:
Alexis Richardson:https://lists.cncf.io/g/cncf-toc/message/4472
Richard Hartmann: https://lists.cncf.io/g/cncf-toc/message/4476
Stephen Augustus: https://lists.cncf.io/g/cncf-toc/message/4477
Ricardo Aravena: https://lists.cncf.io/g/cncf-toc/message/4478
Ron Parker: https://lists.cncf.io/g/cncf-toc/message/4479
Igor Mameshin: https://lists.cncf.io/g/cncf-toc/message/4481
Cornelia Davis: https://lists.cncf.io/g/cncf-toc/message/4483
Navdeep Singh: https://lists.cncf.io/g/cncf-toc/message/4484
Daniel Kleuser: https://lists.cncf.io/g/cncf-toc/message/4486
Alex Chircop: https://lists.cncf.io/g/cncf-toc/message/4489
Matt Young: https://lists.cncf.io/g/cncf-toc/message/4490
Syah Dwi Prihatmoko: https://lists.cncf.io/g/cncf-toc/message/4491
Philippe Robin: https://lists.cncf.io/g/cncf-toc/message/4495
Chris Wright: https://lists.cncf.io/g/cncf-toc/message/4496
Alois Reitbauer: https://lists.cncf.io/g/cncf-toc/message/4497
Kiran Mova: https://lists.cncf.io/g/cncf-toc/message/4498
Fahad Arshad: https://lists.cncf.io/g/cncf-toc/message/4503
Jon Mittelhauser: https://lists.cncf.io/g/cncf-toc/message/4504
Naren Narendra: https://lists.cncf.io/g/cncf-toc/message/4505
Tina Tsou: https://lists.cncf.io/g/cncf-toc/message/4507
Randy Abernethy: https://lists.cncf.io/g/cncf-toc/message/4508
Paul Buck: https://lists.cncf.io/g/cncf-toc/message/4509
--
Amye Scavarda Perrin | Program Manager | amye@...


Re: [RESULT] SIG Observability Approved

alexis richardson
 

Applause! 


On Mon, 6 Apr 2020, 20:22 Amye Scavarda Perrin, <ascavarda@...> wrote:
Brendan Burns has called for a vote on SIG Observability: https://github.com/cncf/sig-observability/pull/1
Welcome new SIG! 

+1 Binding: 8/10
Brendan Burns: https://lists.cncf.io/g/cncf-toc/message/4471
Sheng Liang: https://lists.cncf.io/g/cncf-toc/message/4493
Justin Cormack: https://lists.cncf.io/g/cncf-toc/message/4473
Matt Klein: https://lists.cncf.io/g/cncf-toc/message/4474
Alena Prokharchyk: https://lists.cncf.io/g/cncf-toc/message/4480
Liz Rice: https://lists.cncf.io/g/cncf-toc/message/4482
Katie Gamanji: https://lists.cncf.io/g/cncf-toc/message/4488
Michelle Noorali: https://lists.cncf.io/g/cncf-toc/message/4506

+1 NB:
Alexis Richardson:https://lists.cncf.io/g/cncf-toc/message/4472
Richard Hartmann: https://lists.cncf.io/g/cncf-toc/message/4476
Stephen Augustus: https://lists.cncf.io/g/cncf-toc/message/4477
Ricardo Aravena: https://lists.cncf.io/g/cncf-toc/message/4478
Ron Parker: https://lists.cncf.io/g/cncf-toc/message/4479
Igor Mameshin: https://lists.cncf.io/g/cncf-toc/message/4481
Cornelia Davis: https://lists.cncf.io/g/cncf-toc/message/4483
Navdeep Singh: https://lists.cncf.io/g/cncf-toc/message/4484
Daniel Kleuser: https://lists.cncf.io/g/cncf-toc/message/4486
Alex Chircop: https://lists.cncf.io/g/cncf-toc/message/4489
Matt Young: https://lists.cncf.io/g/cncf-toc/message/4490
Syah Dwi Prihatmoko: https://lists.cncf.io/g/cncf-toc/message/4491
Philippe Robin: https://lists.cncf.io/g/cncf-toc/message/4495
Chris Wright: https://lists.cncf.io/g/cncf-toc/message/4496
Alois Reitbauer: https://lists.cncf.io/g/cncf-toc/message/4497
Kiran Mova: https://lists.cncf.io/g/cncf-toc/message/4498
Fahad Arshad: https://lists.cncf.io/g/cncf-toc/message/4503
Jon Mittelhauser: https://lists.cncf.io/g/cncf-toc/message/4504
Naren Narendra: https://lists.cncf.io/g/cncf-toc/message/4505
Tina Tsou: https://lists.cncf.io/g/cncf-toc/message/4507
Randy Abernethy: https://lists.cncf.io/g/cncf-toc/message/4508
Paul Buck: https://lists.cncf.io/g/cncf-toc/message/4509
--
Amye Scavarda Perrin | Program Manager | amye@...


[RESULT] SIG Observability Approved

Amye Scavarda Perrin
 

Brendan Burns has called for a vote on SIG Observability: https://github.com/cncf/sig-observability/pull/1
Welcome new SIG! 

+1 Binding: 8/10
Brendan Burns: https://lists.cncf.io/g/cncf-toc/message/4471
Sheng Liang: https://lists.cncf.io/g/cncf-toc/message/4493
Justin Cormack: https://lists.cncf.io/g/cncf-toc/message/4473
Matt Klein: https://lists.cncf.io/g/cncf-toc/message/4474
Alena Prokharchyk: https://lists.cncf.io/g/cncf-toc/message/4480
Liz Rice: https://lists.cncf.io/g/cncf-toc/message/4482
Katie Gamanji: https://lists.cncf.io/g/cncf-toc/message/4488
Michelle Noorali: https://lists.cncf.io/g/cncf-toc/message/4506

+1 NB:
Alexis Richardson:https://lists.cncf.io/g/cncf-toc/message/4472
Richard Hartmann: https://lists.cncf.io/g/cncf-toc/message/4476
Stephen Augustus: https://lists.cncf.io/g/cncf-toc/message/4477
Ricardo Aravena: https://lists.cncf.io/g/cncf-toc/message/4478
Ron Parker: https://lists.cncf.io/g/cncf-toc/message/4479
Igor Mameshin: https://lists.cncf.io/g/cncf-toc/message/4481
Cornelia Davis: https://lists.cncf.io/g/cncf-toc/message/4483
Navdeep Singh: https://lists.cncf.io/g/cncf-toc/message/4484
Daniel Kleuser: https://lists.cncf.io/g/cncf-toc/message/4486
Alex Chircop: https://lists.cncf.io/g/cncf-toc/message/4489
Matt Young: https://lists.cncf.io/g/cncf-toc/message/4490
Syah Dwi Prihatmoko: https://lists.cncf.io/g/cncf-toc/message/4491
Philippe Robin: https://lists.cncf.io/g/cncf-toc/message/4495
Chris Wright: https://lists.cncf.io/g/cncf-toc/message/4496
Alois Reitbauer: https://lists.cncf.io/g/cncf-toc/message/4497
Kiran Mova: https://lists.cncf.io/g/cncf-toc/message/4498
Fahad Arshad: https://lists.cncf.io/g/cncf-toc/message/4503
Jon Mittelhauser: https://lists.cncf.io/g/cncf-toc/message/4504
Naren Narendra: https://lists.cncf.io/g/cncf-toc/message/4505
Tina Tsou: https://lists.cncf.io/g/cncf-toc/message/4507
Randy Abernethy: https://lists.cncf.io/g/cncf-toc/message/4508
Paul Buck: https://lists.cncf.io/g/cncf-toc/message/4509
--
Amye Scavarda Perrin | Program Manager | amye@...


Re: [Vote] Argo Project Proposal

ryota.sawada@...
 

+1 non-binding

On Thu, 19 Mar 2020 at 14:20, Amye Scavarda Perrin <ascavarda@...> wrote:
The Argo project is being proposed as an incubation level CNCF project, sponsored by Michelle Noorali from the TOC: https://github.com/argoproj/argo

Please vote (+1/0/-1) by replying to this thread; the full project proposal located here: https://github.com/cncf/toc/pull/299

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 on SIG-Observability Charter

Paul Buck
 


+1, non-binding



On Fri, Apr 3, 2020 at 1:27 PM Randy Abernethy <randy.abernethy@...> wrote:
+1 nb

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.abernethy@...


Re: Vote on SIG-Observability Charter

Randy Abernethy
 

+1 nb

-- 
Randy Abernethy
Managing Partner
RX-M, LLC
randy.abernethy@...


Re: Vote on SIG-Observability Charter

Tina Tsou
 

Dear all,

+1, non binding.


Thank you,
Tina ^ ^

On Apr 3, 2020, at 10:23 AM, Michelle Noorali via lists.cncf.io <michelle.noorali=gmail.com@...> wrote:


+1 binding

On Fri, Apr 3, 2020 at 1:13 PM Naren Narendra via lists.cncf.io <narendra=diamanti.com@...> wrote:

+1 NB

 

From: cncf-toc@... <cncf-toc@...> On Behalf Of Brendan Burns via Lists.Cncf.Io
Sent: Wednesday, April 1, 2020 9:13 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] Vote on SIG-Observability Charter

 

Folks,

As the ToC Liason, I'd like to call a vote on creating SIG-Observability.

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: Vote on SIG-Observability Charter

Michelle Noorali <michelle.noorali@...>
 

+1 binding

On Fri, Apr 3, 2020 at 1:13 PM Naren Narendra via lists.cncf.io <narendra=diamanti.com@...> wrote:

+1 NB

 

From: cncf-toc@... <cncf-toc@...> On Behalf Of Brendan Burns via Lists.Cncf.Io
Sent: Wednesday, April 1, 2020 9:13 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] Vote on SIG-Observability Charter

 

Folks,

As the ToC Liason, I'd like to call a vote on creating SIG-Observability.


Re: Vote on SIG-Observability Charter

Naren Narendra
 

+1 NB

 

From: cncf-toc@... <cncf-toc@...> On Behalf Of Brendan Burns via Lists.Cncf.Io
Sent: Wednesday, April 1, 2020 9:13 AM
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] Vote on SIG-Observability Charter

 

Folks,

As the ToC Liason, I'd like to call a vote on creating SIG-Observability.


Re: Vote on SIG-Observability Charter

Jon Mittelhauser
 

+1 nb

 

From: <cncf-toc@...> on behalf of Fahad Arshad <fahad.arshad@...>
Date: Friday, April 3, 2020 at 5:13 AM
To: <cncf-toc@...>
Subject: Re: [cncf-toc] Vote on SIG-Observability Charter

 

+1, nb

Fahad Arshad


Re: Vote on SIG-Observability Charter

Fahad Arshad
 

+1, nb

Fahad Arshad


Re: [cncf-gb] GB-TOC joint meeting

alexis richardson
 

+1 thanks Eduardo

Quinton

I understand and I think agree with the principles, but I don't think the details are clear.  Let me list some examples.

1) Nats has non-Synadia maintainers & core maintainers.  In the event of Synadia stepping back for any reason, maintainers could also step into core roles.

2) Let's say that Synadia added 3 more core maintainers from end user firms.  Would that lower the risk of project failure?  In which scenarios?  (eg funding, capture, deus ex machina)  How would the LF and CNCF be able to help?  In my view a key VALUE ADD of CNCF should be to help Nats succeed with current governance *and* provide non-market mechanisms to help Nats in extremis.  Users should be reassured because of what CNCF can and will do in the event of Nats hitting difficulties.

3) Which projects are most at risk and why?  
* CNCF Nats
* CNCF Envoy
* Hashicorp Vault
* Hashicorp Nomad
* Apache Kafka

-

alexis






On Thu, Apr 2, 2020 at 11:46 PM Eduardo Silva <eduardo@...> wrote:
...about NATS towards graduation:

Maintenance of a project is critical, we all agree on that. Now I think is important to consider in the equation "which other companies contribute to the project"; I see the following contributions in the NATS devstats dashboard:


Contributors are:

1. Synadia
2. Independent 
3. Cruise
4. Codiicon
5. Global Nuclear Fuel - Americas
6. VMware
...

I see the project has a lot of traction and joined incubation two years ago, in addition, I found NATS it's pretty similar to Fluentd: a strong core with several individual/companies contributing to different components of its ecosystem, with ecosystem I mean SDKs and other stuff.

Nats-server is primarily maintained by Synadia and Google, while the nats-operator has another maintainer which is not related to Synadia (per my understanding): 


Despite I see one company paying the bills and supporting the majority of core maintainers, I see other external maintainers. The project was started in 2014 and it has a lot of traction since then. I am sure there are hundreds of end users, but I doubt they have an interest in to become maintainers (the same thing happened on Fluentd)

I think the project and its ecosystem is very healthy, at least I see serious companies already vouch for it. 

note: not sure if it counts or not, but NATS has a book :)

regards, 


On Thu, Apr 2, 2020 at 1:49 PM Quinton Hoole <quinton@...> wrote:
Regarding requiring multiple maintainer organizations for graduated projects, specifically:

Alexis: "Let's make sure that we are super clear on *what and why* we want from
multiple maintainers at graduation.  For me the outstanding
consideration is that a project should survive wipe out of the team.
An ISV could get "more maintainers" from end user firms, and graduate
its project.  Is it then risk-free?  NO.   So what are we trying to
achieve?"

I've also discussed this at length with the NATS folks.  I'll repeat the essence of the conversation here.  I don't think it's about being 100% risk-free. But let's face it, if only one organization is de-facto maintaining a project, and that organization decides to no longer do so (of simply ceases to exist), then users of the project may find themselves in a bad situation. Given that this sort of thing happens a lot (organizations changing strategy and which projects they fund, and startups disappearing) the chances of this happening are high.  The intention of requiring more than one maintainer org, is primarily to bring that probability down significantly. 

So the ultimate litmus test is, in my opinion, what are the chances of the project ceasing to be effectively maintained?  One simple argument is that there are 3 maintaining organizations, the chances of all of them defunding, or ceasing to exist, is sufficiently low. IMO, if there is only one maintaining organization, particularly if it is a relatively small organization, then the probability it unacceptably high for us to label the project as Graduated.


On Sun, Mar 29, 2020 at 12:12 PM alexis richardson <alexis@...> wrote:
Please can I put in a word for Nats, and its backers.  I think many
others are in a similar situation or could be.

Some projects have a core that is driven by a single vendor (ISV).  We
need to make sure that ISVs have a happy path all the way through CNCF
- and an 'end game'.  They are a vital source of innovation, software
support, community creation.  Their posture to OSS projects can be
different from Big IT, eg it can be less inhibited.

Historically foundations have been good at creating a way for big
vendors to work on one codebase, alongside a community of individual
contributors.  Long may this continue.

More recently CNCF and to some extent CFF have worked hard to bring in
End Users, as we call large companies who are not in the business of
selling software or SaaS, but who can make it (much) better through
their use of that software and iteration therefrom.  This is Fantastic
and for me a key step forward CNCF has taken eg with great projects
like Prometheus, Envoy and now Argo that come from end user tech
firms. Innovation can now come from end users *and be driven into the
mainstream*.

But there is a fourth "leg of the table" in this new level playing
field of Big IT, Big End Users, and individuals.  That leg is ISVs
(and SIs) who may be backed customers and/or VCs.  We need these ISVs
and their backers to be actively investing in the foundation, or they
will find a way to exist independent of the commons. Our loss is our
community's loss.

Let's make sure that we are super clear on *what and why* we want from
multiple maintainers at graduation.  For me the outstanding
consideration is that a project should survive wipe out of the team.
An ISV could get "more maintainers" from end user firms, and graduate
its project.  Is it then risk-free?  NO.   So what are we trying to
achieve?

I'm just throwing this out here to start the debate.  I have failed to
find a clear set of answers on my own or in conversation with others
who care about this.

alexis







On Sun, Mar 29, 2020 at 6:11 PM Dan Kohn <dan@...> wrote:
>
> Thanks. Added as slides 127-128 of https://docs.google.com/presentation/d/1JnK8XKxFV2xQJT_fumzUedLhscP-w0CZ-Qs8URjbCG4/.
> --
> Dan Kohn <dan@...> +1-415-233-1000
> Executive Director, Cloud Native Computing Foundation cncf.io
> dankohn.com or book on my calendar: dankohn.com/c
>
>
> On Sun, Mar 29, 2020 at 12:51 PM Liz Rice <liz@...> wrote:
>>
>> Hi everyone,
>>
>> Looking forward to meeting with you all tomorrow. We have two slides (minimalist design!) highlighting the TOC priorities we'd like to discuss in the joint GB-TOC session: https://docs.google.com/presentation/d/1xhuwdKfkh1ROGk_JE6n0mf9xHOWKNFeKeRFGFirHHoY
>>
>> Hope everyone is staying well,
>> Liz
>>
>> --
>> Liz Rice
>> @lizrice | lizrice.com | +44 (0) 780 126 1145
>
>





--
Quinton Hoole
quinton@...



--

Eduardo Silva
Principal Engineer  | Arm
. . . . . . . . . . . . . . . . . . . . . . . . . . . 
m. +506 70138007
Arm.com
Treasuredata.com


   



Re: [cncf-gb] GB-TOC joint meeting

Eduardo Silva
 

...about NATS towards graduation:

Maintenance of a project is critical, we all agree on that. Now I think is important to consider in the equation "which other companies contribute to the project"; I see the following contributions in the NATS devstats dashboard:


Contributors are:

1. Synadia
2. Independent 
3. Cruise
4. Codiicon
5. Global Nuclear Fuel - Americas
6. VMware
...

I see the project has a lot of traction and joined incubation two years ago, in addition, I found NATS it's pretty similar to Fluentd: a strong core with several individual/companies contributing to different components of its ecosystem, with ecosystem I mean SDKs and other stuff.

Nats-server is primarily maintained by Synadia and Google, while the nats-operator has another maintainer which is not related to Synadia (per my understanding): 


Despite I see one company paying the bills and supporting the majority of core maintainers, I see other external maintainers. The project was started in 2014 and it has a lot of traction since then. I am sure there are hundreds of end users, but I doubt they have an interest in to become maintainers (the same thing happened on Fluentd)

I think the project and its ecosystem is very healthy, at least I see serious companies already vouch for it. 

note: not sure if it counts or not, but NATS has a book :)

regards, 


On Thu, Apr 2, 2020 at 1:49 PM Quinton Hoole <quinton@...> wrote:
Regarding requiring multiple maintainer organizations for graduated projects, specifically:

Alexis: "Let's make sure that we are super clear on *what and why* we want from
multiple maintainers at graduation.  For me the outstanding
consideration is that a project should survive wipe out of the team.
An ISV could get "more maintainers" from end user firms, and graduate
its project.  Is it then risk-free?  NO.   So what are we trying to
achieve?"

I've also discussed this at length with the NATS folks.  I'll repeat the essence of the conversation here.  I don't think it's about being 100% risk-free. But let's face it, if only one organization is de-facto maintaining a project, and that organization decides to no longer do so (of simply ceases to exist), then users of the project may find themselves in a bad situation. Given that this sort of thing happens a lot (organizations changing strategy and which projects they fund, and startups disappearing) the chances of this happening are high.  The intention of requiring more than one maintainer org, is primarily to bring that probability down significantly. 

So the ultimate litmus test is, in my opinion, what are the chances of the project ceasing to be effectively maintained?  One simple argument is that there are 3 maintaining organizations, the chances of all of them defunding, or ceasing to exist, is sufficiently low. IMO, if there is only one maintaining organization, particularly if it is a relatively small organization, then the probability it unacceptably high for us to label the project as Graduated.


On Sun, Mar 29, 2020 at 12:12 PM alexis richardson <alexis@...> wrote:
Please can I put in a word for Nats, and its backers.  I think many
others are in a similar situation or could be.

Some projects have a core that is driven by a single vendor (ISV).  We
need to make sure that ISVs have a happy path all the way through CNCF
- and an 'end game'.  They are a vital source of innovation, software
support, community creation.  Their posture to OSS projects can be
different from Big IT, eg it can be less inhibited.

Historically foundations have been good at creating a way for big
vendors to work on one codebase, alongside a community of individual
contributors.  Long may this continue.

More recently CNCF and to some extent CFF have worked hard to bring in
End Users, as we call large companies who are not in the business of
selling software or SaaS, but who can make it (much) better through
their use of that software and iteration therefrom.  This is Fantastic
and for me a key step forward CNCF has taken eg with great projects
like Prometheus, Envoy and now Argo that come from end user tech
firms. Innovation can now come from end users *and be driven into the
mainstream*.

But there is a fourth "leg of the table" in this new level playing
field of Big IT, Big End Users, and individuals.  That leg is ISVs
(and SIs) who may be backed customers and/or VCs.  We need these ISVs
and their backers to be actively investing in the foundation, or they
will find a way to exist independent of the commons. Our loss is our
community's loss.

Let's make sure that we are super clear on *what and why* we want from
multiple maintainers at graduation.  For me the outstanding
consideration is that a project should survive wipe out of the team.
An ISV could get "more maintainers" from end user firms, and graduate
its project.  Is it then risk-free?  NO.   So what are we trying to
achieve?

I'm just throwing this out here to start the debate.  I have failed to
find a clear set of answers on my own or in conversation with others
who care about this.

alexis







On Sun, Mar 29, 2020 at 6:11 PM Dan Kohn <dan@...> wrote:
>
> Thanks. Added as slides 127-128 of https://docs.google.com/presentation/d/1JnK8XKxFV2xQJT_fumzUedLhscP-w0CZ-Qs8URjbCG4/.
> --
> Dan Kohn <dan@...> +1-415-233-1000
> Executive Director, Cloud Native Computing Foundation cncf.io
> dankohn.com or book on my calendar: dankohn.com/c
>
>
> On Sun, Mar 29, 2020 at 12:51 PM Liz Rice <liz@...> wrote:
>>
>> Hi everyone,
>>
>> Looking forward to meeting with you all tomorrow. We have two slides (minimalist design!) highlighting the TOC priorities we'd like to discuss in the joint GB-TOC session: https://docs.google.com/presentation/d/1xhuwdKfkh1ROGk_JE6n0mf9xHOWKNFeKeRFGFirHHoY
>>
>> Hope everyone is staying well,
>> Liz
>>
>> --
>> Liz Rice
>> @lizrice | lizrice.com | +44 (0) 780 126 1145
>
>





--
Quinton Hoole
quinton@...



--

Eduardo Silva
Principal Engineer  | Arm
. . . . . . . . . . . . . . . . . . . . . . . . . . . 
m. +506 70138007
Arm.com
Treasuredata.com


   



Re: [cncf-gb] GB-TOC joint meeting

Quinton Hoole <quinton@...>
 

Regarding requiring multiple maintainer organizations for graduated projects, specifically:

Alexis: "Let's make sure that we are super clear on *what and why* we want from
multiple maintainers at graduation.  For me the outstanding
consideration is that a project should survive wipe out of the team.
An ISV could get "more maintainers" from end user firms, and graduate
its project.  Is it then risk-free?  NO.   So what are we trying to
achieve?"

I've also discussed this at length with the NATS folks.  I'll repeat the essence of the conversation here.  I don't think it's about being 100% risk-free. But let's face it, if only one organization is de-facto maintaining a project, and that organization decides to no longer do so (of simply ceases to exist), then users of the project may find themselves in a bad situation. Given that this sort of thing happens a lot (organizations changing strategy and which projects they fund, and startups disappearing) the chances of this happening are high.  The intention of requiring more than one maintainer org, is primarily to bring that probability down significantly. 

So the ultimate litmus test is, in my opinion, what are the chances of the project ceasing to be effectively maintained?  One simple argument is that there are 3 maintaining organizations, the chances of all of them defunding, or ceasing to exist, is sufficiently low. IMO, if there is only one maintaining organization, particularly if it is a relatively small organization, then the probability it unacceptably high for us to label the project as Graduated.


On Sun, Mar 29, 2020 at 12:12 PM alexis richardson <alexis@...> wrote:
Please can I put in a word for Nats, and its backers.  I think many
others are in a similar situation or could be.

Some projects have a core that is driven by a single vendor (ISV).  We
need to make sure that ISVs have a happy path all the way through CNCF
- and an 'end game'.  They are a vital source of innovation, software
support, community creation.  Their posture to OSS projects can be
different from Big IT, eg it can be less inhibited.

Historically foundations have been good at creating a way for big
vendors to work on one codebase, alongside a community of individual
contributors.  Long may this continue.

More recently CNCF and to some extent CFF have worked hard to bring in
End Users, as we call large companies who are not in the business of
selling software or SaaS, but who can make it (much) better through
their use of that software and iteration therefrom.  This is Fantastic
and for me a key step forward CNCF has taken eg with great projects
like Prometheus, Envoy and now Argo that come from end user tech
firms. Innovation can now come from end users *and be driven into the
mainstream*.

But there is a fourth "leg of the table" in this new level playing
field of Big IT, Big End Users, and individuals.  That leg is ISVs
(and SIs) who may be backed customers and/or VCs.  We need these ISVs
and their backers to be actively investing in the foundation, or they
will find a way to exist independent of the commons. Our loss is our
community's loss.

Let's make sure that we are super clear on *what and why* we want from
multiple maintainers at graduation.  For me the outstanding
consideration is that a project should survive wipe out of the team.
An ISV could get "more maintainers" from end user firms, and graduate
its project.  Is it then risk-free?  NO.   So what are we trying to
achieve?

I'm just throwing this out here to start the debate.  I have failed to
find a clear set of answers on my own or in conversation with others
who care about this.

alexis







On Sun, Mar 29, 2020 at 6:11 PM Dan Kohn <dan@...> wrote:
>
> Thanks. Added as slides 127-128 of https://docs.google.com/presentation/d/1JnK8XKxFV2xQJT_fumzUedLhscP-w0CZ-Qs8URjbCG4/.
> --
> Dan Kohn <dan@...> +1-415-233-1000
> Executive Director, Cloud Native Computing Foundation cncf.io
> dankohn.com or book on my calendar: dankohn.com/c
>
>
> On Sun, Mar 29, 2020 at 12:51 PM Liz Rice <liz@...> wrote:
>>
>> Hi everyone,
>>
>> Looking forward to meeting with you all tomorrow. We have two slides (minimalist design!) highlighting the TOC priorities we'd like to discuss in the joint GB-TOC session: https://docs.google.com/presentation/d/1xhuwdKfkh1ROGk_JE6n0mf9xHOWKNFeKeRFGFirHHoY
>>
>> Hope everyone is staying well,
>> Liz
>>
>> --
>> Liz Rice
>> @lizrice | lizrice.com | +44 (0) 780 126 1145
>
>





--
Quinton Hoole
quinton@...


Re: [Vote] Argo Project Proposal

Peter Rosell
 

+1 nb

On Thu, Mar 19, 2020 at 3:20 PM Amye Scavarda Perrin via Lists.Cncf.Io <ascavarda=linuxfoundation.org@...> wrote:
The Argo project is being proposed as an incubation level CNCF project, sponsored by Michelle Noorali from the TOC: https://github.com/argoproj/argo

Please vote (+1/0/-1) by replying to this thread; the full project proposal located here: https://github.com/cncf/toc/pull/299

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



--
Peter Rosell
Senior Software Developer / DevOps

Phone: +46 (0) 10 457 67 63
peter.rosell@...

Pagero
www.pagero.com

Box 11006, SE-404 21 Göteborg
Visiting address: Västra Hamngatan 1, Göteborg

* If you have received this email in error, please notify the sender and delete it. The opinions contained in this email are those of the sender and do not reflect those of the company. You have the right to know how we process and use your personal information; please read our Privacy policy to find out more


Re: Vote on SIG-Observability Charter

Kiran Mova
 

+1 non-binding

On Thu, Apr 2, 2020 at 6:34 PM Reitbauer, Alois <alois.reitbauer@...> wrote:

+1, nb

 

From: <cncf-toc@...> on behalf of "Chris Wright via lists.cncf.io" <chrisw=redhat.com@...>
Reply to: "chrisw@..." <chrisw@...>
Date: Thursday, 2. April 2020 at 14:47
To: Brendan Burns <bburns@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] Vote on SIG-Observability Charter

 

+1, non-binding

 

great looking start on a such an important topic

 

On Wed, Apr 1, 2020 at 12:15 PM Brendan Burns via Lists.Cncf.Io <bburns=microsoft.com@...> wrote:

Folks,

As the ToC Liason, I'd like to call a vote on creating SIG-Observability.

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20


Re: Vote on SIG-Observability Charter

Reitbauer, Alois
 

+1, nb

 

From: <cncf-toc@...> on behalf of "Chris Wright via lists.cncf.io" <chrisw=redhat.com@...>
Reply to: "chrisw@..." <chrisw@...>
Date: Thursday, 2. April 2020 at 14:47
To: Brendan Burns <bburns@...>
Cc: CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] Vote on SIG-Observability Charter

 

+1, non-binding

 

great looking start on a such an important topic

 

On Wed, Apr 1, 2020 at 12:15 PM Brendan Burns via Lists.Cncf.Io <bburns=microsoft.com@...> wrote:

Folks,

As the ToC Liason, I'd like to call a vote on creating SIG-Observability.

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4020 Linz, Austria, Am Fünfundzwanziger Turm 20


Re: Vote on SIG-Observability Charter

Chris Wright
 

+1, non-binding

great looking start on a such an important topic

On Wed, Apr 1, 2020 at 12:15 PM Brendan Burns via Lists.Cncf.Io <bburns=microsoft.com@...> wrote:
Folks,
As the ToC Liason, I'd like to call a vote on creating SIG-Observability.


Re: Vote on SIG-Observability Charter

Philippe Robin
 

+1, nb

 

Philippe

 

From: cncf-toc@... <cncf-toc@...> On Behalf Of Brendan Burns via Lists.Cncf.Io
Sent: 01 April 2020 17:13
To: CNCF TOC <cncf-toc@...>
Subject: [cncf-toc] Vote on SIG-Observability Charter

 

Folks,

As the ToC Liason, I'd like to call a vote on creating SIG-Observability.

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: [VOTE] Dragonfly Incubation Vote

Kiran Mova
 

+1 non-binding


On Thu, Apr 2, 2020 at 10:16 AM Brewer, Jeff via lists.cncf.io <jeff_brewer=intuit.com@...> wrote:
+1 binding


On Mar 31, 2020, at 10:37 AM, Michelle Noorali <michelle.noorali@...> wrote:


This email is from an external sender.

+1 binding

On Mar 31, 2020, at 12:54 PM, Liz Rice <liz@...> wrote:

+1 binding

If Dragonfly does indeed move to incubation, it would be great to have SIG Security do an assessment and give recommendations to the project (the related issue is currently marked inactive)

--
Liz Rice
@lizrice | lizrice.com | +44 (0) 780 126 1145



On 26 Mar 2020, at 20:01, Daniel Kleuser <daniel.kleuser@...> wrote:

+1 nb
 
From: <cncf-toc@...> on behalf of "Alena Prokharchyk via Lists.Cncf.Io" <aprokharchyk=apple.com@...>
Reply to: "aprokharchyk@..." <aprokharchyk@...>
Date: Thursday, 26. March 2020 at 17:42
To: Amye Scavarda Perrin <ascavarda@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] [VOTE] Dragonfly Incubation Vote
 
+1 binding 
 


On Mar 13, 2020, at 2:47 PM, Amye Scavarda Perrin <ascavarda@...> wrote:
 
Dragonfly has requested to move to the incubation maturity level:
https://github.com/cncf/toc/pull/276

Sheng Liang from the TOC has performed due diligence and called the vote:
https://github.com/cncf/toc/pull/276#issuecomment-585431207
https://github.com/cncf/toc/pull/276#issuecomment-598923143

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


2681 - 2700 of 7189