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

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

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

+1 nb

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

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

 

You can find the relevant info here:

• PR: https://github.com/cncf/sig-observability/pull/1
• Pretty: https://github.com/cncf/sig-observability/blob/sig-observability-charter/observability-charter.md
• Slide from recent TOC Meeting

I'm +1, Binding 🙂

 

--brendan

 

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

https://nats.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=contributions

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): 

https://github.com/nats-io/nats-operator/blob/master/MAINTAINERS.md

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

   

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

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

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

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

 

You can find the relevant info here:

• PR: https://github.com/cncf/sig-observability/pull/1
• Pretty: https://github.com/cncf/sig-observability/blob/sig-observability-charter/observability-charter.md
• Slide from recent TOC Meeting

I'm +1, Binding 🙂

 

--brendan

 

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

Folks,

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

You can find the relevant info here:

• PR: https://github.com/cncf/sig-observability/pull/1
• Pretty: https://github.com/cncf/sig-observability/blob/sig-observability-charter/observability-charter.md
• Slide from recent TOC Meeting

I'm +1, Binding 🙂

--brendan