Date   

Re: sig contributor strategy charter ready for vote

Owens, Ken
 

+1 nb

 

Ken Owens

Vice President

Software Development Engineering

 

Mastercard

 

From: cncf-toc@... <cncf-toc@...> On Behalf Of Jon Mittelhauser
Sent: Friday, March 13, 2020 11:07 AM
To: Michelle Noorali <michelle.noorali@...>; kiran.mova@...
Cc: Stephen Augustus <Stephen@...>; Paris Pittman <parispittman@...>; CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] sig contributor strategy charter ready for vote

 

CAUTION: The message originated from an EXTERNAL SOURCE. Please use caution when opening attachments, clicking links or responding to this email.

 

+1 nb

 

From: <cncf-toc@...> on behalf of Michelle Noorali <michelle.noorali@...>
Date: Friday, March 13, 2020 at 8:22 AM
To: <kiran.mova@...>
Cc: Stephen Augustus <Stephen@...>, Paris Pittman <parispittman@...>, CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] sig contributor strategy charter ready for vote

 

+1 binding

 

Looks great. Thank you!

 

On Fri, Mar 13, 2020 at 12:12 AM Kiran Mova <kiran.mova@...> wrote:

+1 non-binding

 


--

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

 

 

On Fri, Mar 13, 2020 at 8:14 AM Stephen Augustus <Stephen@...> wrote:

+1 NB!!

Looking forward to this!! :)

 

On Thu, Mar 12, 2020, 21:55 Paris Pittman via Lists.Cncf.Io <parispittman=google.com@...> wrote:

Hi TOC:

 

We are ready for a vote. I know many of you gave +1s when we initially proposed this with the last iteration of TOC, but we are now ready for the final vote with the new crew. 

 

 

Matt Klein as TOC Liaison (others?)

 

thank you!

contributor strategy crowd

 

 

 


 

--

 

Paris Pittman

Kubernetes Community

Open Source Strategy, Google Cloud

345 Spear Street, San Francisco, 94105

 

CONFIDENTIALITY NOTICE This e-mail message and any attachments are only for the use of the intended recipient and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, any disclosure, distribution or other use of this e-mail message or attachments is prohibited. If you have received this e-mail message in error, please delete and notify the sender immediately. Thank you.


Re: sig contributor strategy charter ready for vote

Jon Mittelhauser
 

+1 nb

 

From: <cncf-toc@...> on behalf of Michelle Noorali <michelle.noorali@...>
Date: Friday, March 13, 2020 at 8:22 AM
To: <kiran.mova@...>
Cc: Stephen Augustus <Stephen@...>, Paris Pittman <parispittman@...>, CNCF TOC <cncf-toc@...>
Subject: Re: [cncf-toc] sig contributor strategy charter ready for vote

 

+1 binding

 

Looks great. Thank you!

 

On Fri, Mar 13, 2020 at 12:12 AM Kiran Mova <kiran.mova@...> wrote:

+1 non-binding

 


 

 

On Fri, Mar 13, 2020 at 8:14 AM Stephen Augustus <Stephen@...> wrote:

+1 NB!!

Looking forward to this!! :)

 

On Thu, Mar 12, 2020, 21:55 Paris Pittman via Lists.Cncf.Io <parispittman=google.com@...> wrote:

Hi TOC:

 

We are ready for a vote. I know many of you gave +1s when we initially proposed this with the last iteration of TOC, but we are now ready for the final vote with the new crew. 

 

 

Matt Klein as TOC Liaison (others?)

 

thank you!

contributor strategy crowd

 

 

 


 

--

 

Paris Pittman

Kubernetes Community

Open Source Strategy, Google Cloud

345 Spear Street, San Francisco, 94105

 


Re: sig contributor strategy charter ready for vote

Alena Prokharchyk
 

+1 non-binding 

On Mar 12, 2020, at 6:55 PM, Paris Pittman via Lists.Cncf.Io <parispittman=google.com@...> wrote:

Hi TOC:

We are ready for a vote. I know many of you gave +1s when we initially proposed this with the last iteration of TOC, but we are now ready for the final vote with the new crew. 


Matt Klein as TOC Liaison (others?)

thank you!
contributor strategy crowd





--

Paris Pittman
Kubernetes Community
Open Source Strategy, Google Cloud
345 Spear Street, San Francisco, 94105



Re: sig contributor strategy charter ready for vote

Michelle Noorali <michelle.noorali@...>
 

+1 binding

Looks great. Thank you!


On Fri, Mar 13, 2020 at 12:12 AM Kiran Mova <kiran.mova@...> wrote:
+1 non-binding
 

On Fri, Mar 13, 2020 at 8:14 AM Stephen Augustus <Stephen@...> wrote:
+1 NB!!
Looking forward to this!! :)

On Thu, Mar 12, 2020, 21:55 Paris Pittman via Lists.Cncf.Io <parispittman=google.com@...> wrote:
Hi TOC:

We are ready for a vote. I know many of you gave +1s when we initially proposed this with the last iteration of TOC, but we are now ready for the final vote with the new crew. 


Matt Klein as TOC Liaison (others?)

thank you!
contributor strategy crowd





--

Paris Pittman

Kubernetes Community

Open Source Strategy, Google Cloud

345 Spear Street, San Francisco, 94105



Re: [EXTERNAL] Re: [cncf-toc] Point of process

Brian Grant
 

On Thu, Mar 12, 2020 at 11:00 PM Ricardo Aravena <raravena80@...> wrote:
Pitching in here,

I think most would agree that ideally tools and projects need to be shared openly from their conception.

However, I think from the usability point of view we also want to have a common interface/endpoint (or open standard) to share things like helm charts, rules, policies, operators, etc.

The CNCF Hub looks very Helm-specific and not obviously extensible, so it's not clear to me how it intends to accomplish this:
 
Having separate tools for similar uses generates end user confusion and it may lead them to drop using the projects altogether. Every interface/endpoint that a user needs to set up may add up to a new deployment, new database or datastore, new secrets that need to be rotated, new load balancer, new DNS entry, new client endpoints and so on.

Also, most end users get FUD at the notion of anything 'lock-in'. IMO it's in the project's best interest to interoperate with an open artifacts standard.

Since things are pretty much in flux in terms of processes, whether just having interoperability (if applicable) in the project's roadmap as criteria for Incubation or Graduation is enough is yet up for discussion AFAIK.

Cheers,
Ricardo


On Thu, Mar 12, 2020 at 5:19 PM Matt Farina <matt@...> wrote:
All of these discussion got me thinking about a few things. I figured I'd share.

First, I agree this should have been done in the open from the start. While I didn't run the show and I did ask for this to be open sooner I spent quite a period of time not paying attention and didn't push the issue until this week when it was opened. I'm sorry I didn't do that sooner. I think this is a wonderful lesson learned but shouldn't be the central point moving forward because...

I was reading the foundation charter again and was reminded that the CNCF is there to foster and support projects. For those of us who work on projects this is a benefit for both the projects and their users. The focus, I would think, should be here.

With that in mind, I was asked some questions about the CNCF Hub today and figured I'd share what my 2 cents were. They may not carry much but I did take some time to think them out.

First, the idea of the Hub was for CNCF projects. These aren't vendor controlled open source projects. They are CNCF projects in a vendor neutral home.

Second, I saw this in the support and foster areas as easy discovery and installation of artifacts which is extremely beneficial for uptake. While this has benefited Helm it would be an amazing benefit for other current CNCF projects with artifacts. It would help them foster growth which is a criteria for graduation.

Third, the design for the Hub was intentionally not to be a host for the artifacts. Current vendors do a lot of artifact hosting and this doesn't do that. Instead, it's a distributed search system that lists what's public in those systems. The UX benefit helps the projects distributed artifacts be more easily accessible which is important for users of the projects and the projects themselves.

All of this is under the guise of fostering and supporting projects which is a task of the CNCF.

I'm also reminded of the many services the CNCF provides projects. Devstats, conference hosting, and other elements. In my mind I see something like a Hub living alongside those in a similar manner. Though, I imagine this point is up for debate.

As this has impact on existing CNCF projects - Helm, Falco, and OPA come to mind - I would like to see a lively conversation among the existing projects who would be impacted. Do they want a single hub? Do they want a shared codebase that can be used for individual hubs? What's a better cloud native consumer experience for people to find artifacts?

I know this whole conversation impacts the operator framework which is unfortunate. But, I would appreciate if the topic of the conversation in this coming meeting is in the positive direction around supporting the projects.

Thanks for listening,
Matt Farina



On Thu, Mar 12, 2020, at 2:26 PM, Brendan Burns via Lists.Cncf.Io wrote:
100% agree with encouraging diversity and not being king makers.

However, I also think that applies within projects, not just between projects.

I want to make sure that we adopt tools that encourage and enable a diversity of people hosting artifacts.

As a concrete example, I would be uncomfortable accepting something like npm (not that they're talking to us) because it is pretty tightly locked to a single web site for discovery.

--brendan





From: Erin Boyd <eboyd@...>
Sent: Thursday, March 12, 2020 11:22 AM
To: Brendan Burns <bburns@...>
Cc: alexis richardson <alexis@...>; CNCF TOC <cncf-toc@...>
Subject: Re: [EXTERNAL] Re: [cncf-toc] Point of process
 
To add to your thought, Brendan...I believe we should be thorough with our technical due diligence and understand what differentiates one project from another in the same space. And the CNCF, like any other company/organization is free to choose the best technology to address their problem space. 
However, I firmly believe that our job (TOC and TOC contributors) are to enable choices and diversity within the landscape. We don't want every project that goes into the cncf to operate exactly the same. There are advantages and disadvantages of both. It's not a one-size-fits-all. 
Ensuring we aren't being King Makers should be a fundamental value we hold in making these decisions.




On Thu, Mar 12, 2020, 11:40 AM Brendan Burns <bburns@...> wrote:
I'm in full agreement regarding transparency in the CNCF.

However, I think the discussion about OperatorHub has more to do with it's intersection with Helm and the Helm Hub as well as whether Operator Hub is built to enable alternate/federated hubs in the way that Helm is.

(there's lots of details on the other threads about OperatorHub)

So I don't think it is accurate to characterize the delay as being due to CNCF Hub, but rather the ToC wrangling with what makes sense around these kinds of artifact discovery mechanisms.

In the interests of not forking the discussion, if people want to discuss OperatorHub technical design let's use the other threads for that.

--brendan





From: cncf-toc@... <cncf-toc@...> on behalf of Erin Boyd via Lists.Cncf.Io <eboyd=redhat.com@...>
Sent: Thursday, March 12, 2020 7:39 AM
To: alexis richardson <alexis@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] Re: [cncf-toc] Point of process
 
Amen!

On Thu, Mar 12, 2020, 4:26 AM alexis richardson <alexis@...> wrote:
I believe the issue here is simple.  The CNCF is an open organisation
and should not develop its own projects in secret.  End of story.  We
saw this happen before eg "cloud native network functions" [1], which
led to collective bafflement from the community, TOC and End Users.

To be clear: I am 100% supportive of the CNCF using resources and
brand to kick projects, RFCs, RFPs, and who knows what.  But please do
it in the OPEN.  The CNCF should not compete with its membership.

[1]



On Thu, Mar 12, 2020 at 5:37 AM Chris Wright <chrisw@...> wrote:
>
> On Wed, Mar 11, 2020, 7:23 PM Liz Rice <liz@...> wrote:
>>
>> Lots to unpack here, Chris, and as it’s 11pm I may not do it full justice in this response but I did want to make a couple of quick points:
>>
>> First come, first served project assessment has been a worry for the TOC ever since I have been involved, if not longer. Accepting a project can be beneficial for that project but might be detrimental for a competing project. So, we try to look at competing / alternative solutions as part of any assessment. The order in which things are submitted is not the most important factor here.
>
>
> Agree with the sentiment here. I'd put it as domain squatting or cookie licking is not healthy for the broader industry.  What I find uncomfortable here is the potential added component of lack of transparency and awkward sense of conflict of interest when it appears to come from CNCF.
>
> Our stated goal is not to be a king maker. One natural outcome is projects with overlapping scope.
>
>> I think we all would have liked CNCF Hub to be made public some time ago.
>
>
> If someone other than CNCF said in private, "hey, we have a great project that nobody uses or has seen, so you should delay your process" I would expect the response to be pretty disinterested. "Thanks for your input, happy to evaluate after you exist."
>>
>> To be fair to Dan, there have been some other pressing concerns to deal with in this time; I still think the project could have been made public sooner, but we are where we are. The TOC was made aware of the project, and I hope you’d agree we should act with all the information we have at our disposal.  It was clear that CNCF Hub would likely have an impact on the CNCF’s overall strategy around artifact discovery and distribution (and the operator hub is clearly in that space).
>
> I guess I'm really struggling not to see reverse cookie licking...despite what's existed for some time (with highly relevant concerns discussed and laid to rest in an open, active SIG community), here's a new and unproven concept...seemingly from CNCF.  It does beg the question: What is CNCF's strategy for artifact discovery and distribution?
>>
>> Considering that strategy properly and calmly is in our view extremely important. We were aware that the delay was frustrating to the OF project and tried to at least give some explanation as to why there was hold-up (hence the comment in the PR that you refer to).
>
>
> Thank you for surfacing in a PR.
>
> The discussion is 13days after the SIG recommendation for acceptance, and draws out a suggestion the OF comply with a new, non-existent concept.
>
>> Over the past few months we have been working to make the project assessment process more scalable and transparent. But IMO process should never trump doing what we believe is the right thing for the community.
>
>
> I agree that process for process sake is the negative expression of beuraucracy.
>
> And I applaud all the work towards scalability and transparency. The task here is onerous and even thankless. So please take this as constructive feedback.
>
> It's why I suggested some clarity on guidelines. Because if we all decide independently on the right thing, we are not a community.
>
>
>>
>> Liz
>>
>> --
>> Liz Rice
>> @lizrice | lizrice.com | +44 (0) 780 126 1145
>> On 11 Mar 2020, 22:33 +0000, Chris Wright <chrisw@...>, wrote:
>>
>> During the evaluation of the Operator Framework for acceptance into
>> the CNCF as an incubation project, I was surprised to learn that the
>> vote was being held up by a request on behalf of a project yet to be
>> submitted to the TOC and SIGs for review. You can see the comment
>>
>> The project, CNCF Hub, was just submitted March 10th to the TOC
>> mailing list as a project intended to be used as the CNCF standard for
>> discovering and installing projects within this ecosystem. This
>> project was mentioned to the community at KubeCon San Diego, but no
>> significant community awareness until March 10th. The project is being
>> released as pre-beta helm based project. The potential appearance of a
>> fait accompli by having this conceptual prototype with a CNCF domain
>> name is one of my concerns, as it can easily give a misleading view of
>> community and CNCF support.
>>
>> As a foundation based on open source and open governance, I can't
>> accept a process that gives a CNCF sponsored project any special path
>> in or ability to hold up another project for consideration.
>>
>> Projects should never be reviewed according to fluid, inconsistent or
>> secretive guidelines.
>>
>> I recommend that we clarify the guidelines to ensure all projects are
>> treated equally and fairly.
>>
>> thanks,
>> -chris
>>
>>
>>
>>
>





Re: sig contributor strategy charter ready for vote

Xing Yang
 

+1 non-binding

On Thu, Mar 12, 2020 at 9:55 PM Paris Pittman via Lists.Cncf.Io <parispittman=google.com@...> wrote:
Hi TOC:

We are ready for a vote. I know many of you gave +1s when we initially proposed this with the last iteration of TOC, but we are now ready for the final vote with the new crew. 


Matt Klein as TOC Liaison (others?)

thank you!
contributor strategy crowd





--

Paris Pittman

Kubernetes Community

Open Source Strategy, Google Cloud

345 Spear Street, San Francisco, 94105



Re: sig contributor strategy charter ready for vote

Justin Cormack
 

+1 (binding)

Justin


On Fri, Mar 13, 2020 at 1:55 AM Paris Pittman via Lists.Cncf.Io <parispittman=google.com@...> wrote:
Hi TOC:

We are ready for a vote. I know many of you gave +1s when we initially proposed this with the last iteration of TOC, but we are now ready for the final vote with the new crew. 


Matt Klein as TOC Liaison (others?)

thank you!
contributor strategy crowd





--

Paris Pittman

Kubernetes Community

Open Source Strategy, Google Cloud

345 Spear Street, San Francisco, 94105



Re: sig contributor strategy charter ready for vote

Liz Rice
 

+1 binding from me, thank you! 

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



On 13 Mar 2020, at 06:44, Ihor Dvoretskyi <ihor@...> wrote:

+1 (nb), thanks Paris and all.

On Fri, Mar 13, 2020, 3:55 AM Paris Pittman via Lists.Cncf.Io<parispittman=google.com@...> wrote:
Hi TOC:

We are ready for a vote. I know many of you gave +1s when we initially proposed this with the last iteration of TOC, but we are now ready for the final vote with the new crew. 


Matt Klein as TOC Liaison (others?)

thank you!
contributor strategy crowd





-- 

Paris Pittman
Kubernetes Community
Open Source Strategy, Google Cloud
345 Spear Street, San Francisco, 94105





Re: sig contributor strategy charter ready for vote

Ihor Dvoretskyi
 

+1 (nb), thanks Paris and all.


On Fri, Mar 13, 2020, 3:55 AM Paris Pittman via Lists.Cncf.Io <parispittman=google.com@...> wrote:
Hi TOC:

We are ready for a vote. I know many of you gave +1s when we initially proposed this with the last iteration of TOC, but we are now ready for the final vote with the new crew. 


Matt Klein as TOC Liaison (others?)

thank you!
contributor strategy crowd





--

Paris Pittman

Kubernetes Community

Open Source Strategy, Google Cloud

345 Spear Street, San Francisco, 94105



Re: [EXTERNAL] Re: [cncf-toc] Point of process

Ricardo Aravena
 

Pitching in here,

I think most would agree that ideally tools and projects need to be shared openly from their conception.

However, I think from the usability point of view we also want to have a common interface/endpoint (or open standard) to share things like helm charts, rules, policies, operators, etc. Having separate tools for similar uses generates end user confusion and it may lead them to drop using the projects altogether. Every interface/endpoint that a user needs to set up may add up to a new deployment, new database or datastore, new secrets that need to be rotated, new load balancer, new DNS entry, new client endpoints and so on.

Also, most end users get FUD at the notion of anything 'lock-in'. IMO it's in the project's best interest to interoperate with an open artifacts standard.

Since things are pretty much in flux in terms of processes, whether just having interoperability (if applicable) in the project's roadmap as criteria for Incubation or Graduation is enough is yet up for discussion AFAIK.

Cheers,
Ricardo


On Thu, Mar 12, 2020 at 5:19 PM Matt Farina <matt@...> wrote:
All of these discussion got me thinking about a few things. I figured I'd share.

First, I agree this should have been done in the open from the start. While I didn't run the show and I did ask for this to be open sooner I spent quite a period of time not paying attention and didn't push the issue until this week when it was opened. I'm sorry I didn't do that sooner. I think this is a wonderful lesson learned but shouldn't be the central point moving forward because...

I was reading the foundation charter again and was reminded that the CNCF is there to foster and support projects. For those of us who work on projects this is a benefit for both the projects and their users. The focus, I would think, should be here.

With that in mind, I was asked some questions about the CNCF Hub today and figured I'd share what my 2 cents were. They may not carry much but I did take some time to think them out.

First, the idea of the Hub was for CNCF projects. These aren't vendor controlled open source projects. They are CNCF projects in a vendor neutral home.

Second, I saw this in the support and foster areas as easy discovery and installation of artifacts which is extremely beneficial for uptake. While this has benefited Helm it would be an amazing benefit for other current CNCF projects with artifacts. It would help them foster growth which is a criteria for graduation.

Third, the design for the Hub was intentionally not to be a host for the artifacts. Current vendors do a lot of artifact hosting and this doesn't do that. Instead, it's a distributed search system that lists what's public in those systems. The UX benefit helps the projects distributed artifacts be more easily accessible which is important for users of the projects and the projects themselves.

All of this is under the guise of fostering and supporting projects which is a task of the CNCF.

I'm also reminded of the many services the CNCF provides projects. Devstats, conference hosting, and other elements. In my mind I see something like a Hub living alongside those in a similar manner. Though, I imagine this point is up for debate.

As this has impact on existing CNCF projects - Helm, Falco, and OPA come to mind - I would like to see a lively conversation among the existing projects who would be impacted. Do they want a single hub? Do they want a shared codebase that can be used for individual hubs? What's a better cloud native consumer experience for people to find artifacts?

I know this whole conversation impacts the operator framework which is unfortunate. But, I would appreciate if the topic of the conversation in this coming meeting is in the positive direction around supporting the projects.

Thanks for listening,
Matt Farina



On Thu, Mar 12, 2020, at 2:26 PM, Brendan Burns via Lists.Cncf.Io wrote:
100% agree with encouraging diversity and not being king makers.

However, I also think that applies within projects, not just between projects.

I want to make sure that we adopt tools that encourage and enable a diversity of people hosting artifacts.

As a concrete example, I would be uncomfortable accepting something like npm (not that they're talking to us) because it is pretty tightly locked to a single web site for discovery.

--brendan





From: Erin Boyd <eboyd@...>
Sent: Thursday, March 12, 2020 11:22 AM
To: Brendan Burns <bburns@...>
Cc: alexis richardson <alexis@...>; CNCF TOC <cncf-toc@...>
Subject: Re: [EXTERNAL] Re: [cncf-toc] Point of process
 
To add to your thought, Brendan...I believe we should be thorough with our technical due diligence and understand what differentiates one project from another in the same space. And the CNCF, like any other company/organization is free to choose the best technology to address their problem space. 
However, I firmly believe that our job (TOC and TOC contributors) are to enable choices and diversity within the landscape. We don't want every project that goes into the cncf to operate exactly the same. There are advantages and disadvantages of both. It's not a one-size-fits-all. 
Ensuring we aren't being King Makers should be a fundamental value we hold in making these decisions.




On Thu, Mar 12, 2020, 11:40 AM Brendan Burns <bburns@...> wrote:
I'm in full agreement regarding transparency in the CNCF.

However, I think the discussion about OperatorHub has more to do with it's intersection with Helm and the Helm Hub as well as whether Operator Hub is built to enable alternate/federated hubs in the way that Helm is.

(there's lots of details on the other threads about OperatorHub)

So I don't think it is accurate to characterize the delay as being due to CNCF Hub, but rather the ToC wrangling with what makes sense around these kinds of artifact discovery mechanisms.

In the interests of not forking the discussion, if people want to discuss OperatorHub technical design let's use the other threads for that.

--brendan





From: cncf-toc@... <cncf-toc@...> on behalf of Erin Boyd via Lists.Cncf.Io <eboyd=redhat.com@...>
Sent: Thursday, March 12, 2020 7:39 AM
To: alexis richardson <alexis@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] Re: [cncf-toc] Point of process
 
Amen!

On Thu, Mar 12, 2020, 4:26 AM alexis richardson <alexis@...> wrote:
I believe the issue here is simple.  The CNCF is an open organisation
and should not develop its own projects in secret.  End of story.  We
saw this happen before eg "cloud native network functions" [1], which
led to collective bafflement from the community, TOC and End Users.

To be clear: I am 100% supportive of the CNCF using resources and
brand to kick projects, RFCs, RFPs, and who knows what.  But please do
it in the OPEN.  The CNCF should not compete with its membership.

[1]



On Thu, Mar 12, 2020 at 5:37 AM Chris Wright <chrisw@...> wrote:
>
> On Wed, Mar 11, 2020, 7:23 PM Liz Rice <liz@...> wrote:
>>
>> Lots to unpack here, Chris, and as it’s 11pm I may not do it full justice in this response but I did want to make a couple of quick points:
>>
>> First come, first served project assessment has been a worry for the TOC ever since I have been involved, if not longer. Accepting a project can be beneficial for that project but might be detrimental for a competing project. So, we try to look at competing / alternative solutions as part of any assessment. The order in which things are submitted is not the most important factor here.
>
>
> Agree with the sentiment here. I'd put it as domain squatting or cookie licking is not healthy for the broader industry.  What I find uncomfortable here is the potential added component of lack of transparency and awkward sense of conflict of interest when it appears to come from CNCF.
>
> Our stated goal is not to be a king maker. One natural outcome is projects with overlapping scope.
>
>> I think we all would have liked CNCF Hub to be made public some time ago.
>
>
> If someone other than CNCF said in private, "hey, we have a great project that nobody uses or has seen, so you should delay your process" I would expect the response to be pretty disinterested. "Thanks for your input, happy to evaluate after you exist."
>>
>> To be fair to Dan, there have been some other pressing concerns to deal with in this time; I still think the project could have been made public sooner, but we are where we are. The TOC was made aware of the project, and I hope you’d agree we should act with all the information we have at our disposal.  It was clear that CNCF Hub would likely have an impact on the CNCF’s overall strategy around artifact discovery and distribution (and the operator hub is clearly in that space).
>
> I guess I'm really struggling not to see reverse cookie licking...despite what's existed for some time (with highly relevant concerns discussed and laid to rest in an open, active SIG community), here's a new and unproven concept...seemingly from CNCF.  It does beg the question: What is CNCF's strategy for artifact discovery and distribution?
>>
>> Considering that strategy properly and calmly is in our view extremely important. We were aware that the delay was frustrating to the OF project and tried to at least give some explanation as to why there was hold-up (hence the comment in the PR that you refer to).
>
>
> Thank you for surfacing in a PR.
>
> The discussion is 13days after the SIG recommendation for acceptance, and draws out a suggestion the OF comply with a new, non-existent concept.
>
>> Over the past few months we have been working to make the project assessment process more scalable and transparent. But IMO process should never trump doing what we believe is the right thing for the community.
>
>
> I agree that process for process sake is the negative expression of beuraucracy.
>
> And I applaud all the work towards scalability and transparency. The task here is onerous and even thankless. So please take this as constructive feedback.
>
> It's why I suggested some clarity on guidelines. Because if we all decide independently on the right thing, we are not a community.
>
>
>>
>> Liz
>>
>> --
>> Liz Rice
>> @lizrice | lizrice.com | +44 (0) 780 126 1145
>> On 11 Mar 2020, 22:33 +0000, Chris Wright <chrisw@...>, wrote:
>>
>> During the evaluation of the Operator Framework for acceptance into
>> the CNCF as an incubation project, I was surprised to learn that the
>> vote was being held up by a request on behalf of a project yet to be
>> submitted to the TOC and SIGs for review. You can see the comment
>>
>> The project, CNCF Hub, was just submitted March 10th to the TOC
>> mailing list as a project intended to be used as the CNCF standard for
>> discovering and installing projects within this ecosystem. This
>> project was mentioned to the community at KubeCon San Diego, but no
>> significant community awareness until March 10th. The project is being
>> released as pre-beta helm based project. The potential appearance of a
>> fait accompli by having this conceptual prototype with a CNCF domain
>> name is one of my concerns, as it can easily give a misleading view of
>> community and CNCF support.
>>
>> As a foundation based on open source and open governance, I can't
>> accept a process that gives a CNCF sponsored project any special path
>> in or ability to hold up another project for consideration.
>>
>> Projects should never be reviewed according to fluid, inconsistent or
>> secretive guidelines.
>>
>> I recommend that we clarify the guidelines to ensure all projects are
>> treated equally and fairly.
>>
>> thanks,
>> -chris
>>
>>
>>
>>
>





Re: sig contributor strategy charter ready for vote

Kiran Mova
 

+1 non-binding
 


On Fri, Mar 13, 2020 at 8:14 AM Stephen Augustus <Stephen@...> wrote:
+1 NB!!
Looking forward to this!! :)

On Thu, Mar 12, 2020, 21:55 Paris Pittman via Lists.Cncf.Io <parispittman=google.com@...> wrote:
Hi TOC:

We are ready for a vote. I know many of you gave +1s when we initially proposed this with the last iteration of TOC, but we are now ready for the final vote with the new crew. 


Matt Klein as TOC Liaison (others?)

thank you!
contributor strategy crowd





--

Paris Pittman

Kubernetes Community

Open Source Strategy, Google Cloud

345 Spear Street, San Francisco, 94105



Re: sig contributor strategy charter ready for vote

Stephen Augustus
 

+1 NB!!
Looking forward to this!! :)

On Thu, Mar 12, 2020, 21:55 Paris Pittman via Lists.Cncf.Io <parispittman=google.com@...> wrote:
Hi TOC:

We are ready for a vote. I know many of you gave +1s when we initially proposed this with the last iteration of TOC, but we are now ready for the final vote with the new crew. 


Matt Klein as TOC Liaison (others?)

thank you!
contributor strategy crowd





--

Paris Pittman

Kubernetes Community

Open Source Strategy, Google Cloud

345 Spear Street, San Francisco, 94105



sig contributor strategy charter ready for vote

Paris Pittman <parispittman@...>
 

Hi TOC:

We are ready for a vote. I know many of you gave +1s when we initially proposed this with the last iteration of TOC, but we are now ready for the final vote with the new crew. 


Matt Klein as TOC Liaison (others?)

thank you!
contributor strategy crowd





--

Paris Pittman

Kubernetes Community

Open Source Strategy, Google Cloud

345 Spear Street, San Francisco, 94105



Re: [EXTERNAL] Re: [cncf-toc] Point of process

Matt Farina
 

All of these discussion got me thinking about a few things. I figured I'd share.

First, I agree this should have been done in the open from the start. While I didn't run the show and I did ask for this to be open sooner I spent quite a period of time not paying attention and didn't push the issue until this week when it was opened. I'm sorry I didn't do that sooner. I think this is a wonderful lesson learned but shouldn't be the central point moving forward because...

I was reading the foundation charter again and was reminded that the CNCF is there to foster and support projects. For those of us who work on projects this is a benefit for both the projects and their users. The focus, I would think, should be here.

With that in mind, I was asked some questions about the CNCF Hub today and figured I'd share what my 2 cents were. They may not carry much but I did take some time to think them out.

First, the idea of the Hub was for CNCF projects. These aren't vendor controlled open source projects. They are CNCF projects in a vendor neutral home.

Second, I saw this in the support and foster areas as easy discovery and installation of artifacts which is extremely beneficial for uptake. While this has benefited Helm it would be an amazing benefit for other current CNCF projects with artifacts. It would help them foster growth which is a criteria for graduation.

Third, the design for the Hub was intentionally not to be a host for the artifacts. Current vendors do a lot of artifact hosting and this doesn't do that. Instead, it's a distributed search system that lists what's public in those systems. The UX benefit helps the projects distributed artifacts be more easily accessible which is important for users of the projects and the projects themselves.

All of this is under the guise of fostering and supporting projects which is a task of the CNCF.

I'm also reminded of the many services the CNCF provides projects. Devstats, conference hosting, and other elements. In my mind I see something like a Hub living alongside those in a similar manner. Though, I imagine this point is up for debate.

As this has impact on existing CNCF projects - Helm, Falco, and OPA come to mind - I would like to see a lively conversation among the existing projects who would be impacted. Do they want a single hub? Do they want a shared codebase that can be used for individual hubs? What's a better cloud native consumer experience for people to find artifacts?

I know this whole conversation impacts the operator framework which is unfortunate. But, I would appreciate if the topic of the conversation in this coming meeting is in the positive direction around supporting the projects.

Thanks for listening,
Matt Farina



On Thu, Mar 12, 2020, at 2:26 PM, Brendan Burns via Lists.Cncf.Io wrote:
100% agree with encouraging diversity and not being king makers.

However, I also think that applies within projects, not just between projects.

I want to make sure that we adopt tools that encourage and enable a diversity of people hosting artifacts.

As a concrete example, I would be uncomfortable accepting something like npm (not that they're talking to us) because it is pretty tightly locked to a single web site for discovery.

--brendan





From: Erin Boyd <eboyd@...>
Sent: Thursday, March 12, 2020 11:22 AM
To: Brendan Burns <bburns@...>
Cc: alexis richardson <alexis@...>; CNCF TOC <cncf-toc@...>
Subject: Re: [EXTERNAL] Re: [cncf-toc] Point of process
 
To add to your thought, Brendan...I believe we should be thorough with our technical due diligence and understand what differentiates one project from another in the same space. And the CNCF, like any other company/organization is free to choose the best technology to address their problem space. 
However, I firmly believe that our job (TOC and TOC contributors) are to enable choices and diversity within the landscape. We don't want every project that goes into the cncf to operate exactly the same. There are advantages and disadvantages of both. It's not a one-size-fits-all. 
Ensuring we aren't being King Makers should be a fundamental value we hold in making these decisions.




On Thu, Mar 12, 2020, 11:40 AM Brendan Burns <bburns@...> wrote:
I'm in full agreement regarding transparency in the CNCF.

However, I think the discussion about OperatorHub has more to do with it's intersection with Helm and the Helm Hub as well as whether Operator Hub is built to enable alternate/federated hubs in the way that Helm is.

(there's lots of details on the other threads about OperatorHub)

So I don't think it is accurate to characterize the delay as being due to CNCF Hub, but rather the ToC wrangling with what makes sense around these kinds of artifact discovery mechanisms.

In the interests of not forking the discussion, if people want to discuss OperatorHub technical design let's use the other threads for that.

--brendan





From: cncf-toc@... <cncf-toc@...> on behalf of Erin Boyd via Lists.Cncf.Io <eboyd=redhat.com@...>
Sent: Thursday, March 12, 2020 7:39 AM
To: alexis richardson <alexis@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] Re: [cncf-toc] Point of process
 
Amen!

On Thu, Mar 12, 2020, 4:26 AM alexis richardson <alexis@...> wrote:
I believe the issue here is simple.  The CNCF is an open organisation
and should not develop its own projects in secret.  End of story.  We
saw this happen before eg "cloud native network functions" [1], which
led to collective bafflement from the community, TOC and End Users.

To be clear: I am 100% supportive of the CNCF using resources and
brand to kick projects, RFCs, RFPs, and who knows what.  But please do
it in the OPEN.  The CNCF should not compete with its membership.

[1]



On Thu, Mar 12, 2020 at 5:37 AM Chris Wright <chrisw@...> wrote:
>
> On Wed, Mar 11, 2020, 7:23 PM Liz Rice <liz@...> wrote:
>>
>> Lots to unpack here, Chris, and as it’s 11pm I may not do it full justice in this response but I did want to make a couple of quick points:
>>
>> First come, first served project assessment has been a worry for the TOC ever since I have been involved, if not longer. Accepting a project can be beneficial for that project but might be detrimental for a competing project. So, we try to look at competing / alternative solutions as part of any assessment. The order in which things are submitted is not the most important factor here.
>
>
> Agree with the sentiment here. I'd put it as domain squatting or cookie licking is not healthy for the broader industry.  What I find uncomfortable here is the potential added component of lack of transparency and awkward sense of conflict of interest when it appears to come from CNCF.
>
> Our stated goal is not to be a king maker. One natural outcome is projects with overlapping scope.
>
>> I think we all would have liked CNCF Hub to be made public some time ago.
>
>
> If someone other than CNCF said in private, "hey, we have a great project that nobody uses or has seen, so you should delay your process" I would expect the response to be pretty disinterested. "Thanks for your input, happy to evaluate after you exist."
>>
>> To be fair to Dan, there have been some other pressing concerns to deal with in this time; I still think the project could have been made public sooner, but we are where we are. The TOC was made aware of the project, and I hope you’d agree we should act with all the information we have at our disposal.  It was clear that CNCF Hub would likely have an impact on the CNCF’s overall strategy around artifact discovery and distribution (and the operator hub is clearly in that space).
>
> I guess I'm really struggling not to see reverse cookie licking...despite what's existed for some time (with highly relevant concerns discussed and laid to rest in an open, active SIG community), here's a new and unproven concept...seemingly from CNCF.  It does beg the question: What is CNCF's strategy for artifact discovery and distribution?
>>
>> Considering that strategy properly and calmly is in our view extremely important. We were aware that the delay was frustrating to the OF project and tried to at least give some explanation as to why there was hold-up (hence the comment in the PR that you refer to).
>
>
> Thank you for surfacing in a PR.
>
> The discussion is 13days after the SIG recommendation for acceptance, and draws out a suggestion the OF comply with a new, non-existent concept.
>
>> Over the past few months we have been working to make the project assessment process more scalable and transparent. But IMO process should never trump doing what we believe is the right thing for the community.
>
>
> I agree that process for process sake is the negative expression of beuraucracy.
>
> And I applaud all the work towards scalability and transparency. The task here is onerous and even thankless. So please take this as constructive feedback.
>
> It's why I suggested some clarity on guidelines. Because if we all decide independently on the right thing, we are not a community.
>
>
>>
>> Liz
>>
>> --
>> Liz Rice
>> @lizrice | lizrice.com | +44 (0) 780 126 1145
>> On 11 Mar 2020, 22:33 +0000, Chris Wright <chrisw@...>, wrote:
>>
>> During the evaluation of the Operator Framework for acceptance into
>> the CNCF as an incubation project, I was surprised to learn that the
>> vote was being held up by a request on behalf of a project yet to be
>> submitted to the TOC and SIGs for review. You can see the comment
>>
>> The project, CNCF Hub, was just submitted March 10th to the TOC
>> mailing list as a project intended to be used as the CNCF standard for
>> discovering and installing projects within this ecosystem. This
>> project was mentioned to the community at KubeCon San Diego, but no
>> significant community awareness until March 10th. The project is being
>> released as pre-beta helm based project. The potential appearance of a
>> fait accompli by having this conceptual prototype with a CNCF domain
>> name is one of my concerns, as it can easily give a misleading view of
>> community and CNCF support.
>>
>> As a foundation based on open source and open governance, I can't
>> accept a process that gives a CNCF sponsored project any special path
>> in or ability to hold up another project for consideration.
>>
>> Projects should never be reviewed according to fluid, inconsistent or
>> secretive guidelines.
>>
>> I recommend that we clarify the guidelines to ensure all projects are
>> treated equally and fairly.
>>
>> thanks,
>> -chris
>>
>>
>>
>>
>





Re: [EXTERNAL] Re: [cncf-toc] Point of process

Brendan Burns
 

100% agree with encouraging diversity and not being king makers.

However, I also think that applies within projects, not just between projects.

I want to make sure that we adopt tools that encourage and enable a diversity of people hosting artifacts.

As a concrete example, I would be uncomfortable accepting something like npm (not that they're talking to us) because it is pretty tightly locked to a single web site for discovery.

--brendan



From: Erin Boyd <eboyd@...>
Sent: Thursday, March 12, 2020 11:22 AM
To: Brendan Burns <bburns@...>
Cc: alexis richardson <alexis@...>; CNCF TOC <cncf-toc@...>
Subject: Re: [EXTERNAL] Re: [cncf-toc] Point of process
 
To add to your thought, Brendan...I believe we should be thorough with our technical due diligence and understand what differentiates one project from another in the same space. And the CNCF, like any other company/organization is free to choose the best technology to address their problem space. 
However, I firmly believe that our job (TOC and TOC contributors) are to enable choices and diversity within the landscape. We don't want every project that goes into the cncf to operate exactly the same. There are advantages and disadvantages of both. It's not a one-size-fits-all. 
Ensuring we aren't being King Makers should be a fundamental value we hold in making these decisions.



On Thu, Mar 12, 2020, 11:40 AM Brendan Burns <bburns@...> wrote:
I'm in full agreement regarding transparency in the CNCF.

However, I think the discussion about OperatorHub has more to do with it's intersection with Helm and the Helm Hub as well as whether Operator Hub is built to enable alternate/federated hubs in the way that Helm is.

(there's lots of details on the other threads about OperatorHub)

So I don't think it is accurate to characterize the delay as being due to CNCF Hub, but rather the ToC wrangling with what makes sense around these kinds of artifact discovery mechanisms.

In the interests of not forking the discussion, if people want to discuss OperatorHub technical design let's use the other threads for that.

--brendan



From: cncf-toc@... <cncf-toc@...> on behalf of Erin Boyd via Lists.Cncf.Io <eboyd=redhat.com@...>
Sent: Thursday, March 12, 2020 7:39 AM
To: alexis richardson <alexis@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] Re: [cncf-toc] Point of process
 
Amen!

On Thu, Mar 12, 2020, 4:26 AM alexis richardson <alexis@...> wrote:
I believe the issue here is simple.  The CNCF is an open organisation
and should not develop its own projects in secret.  End of story.  We
saw this happen before eg "cloud native network functions" [1], which
led to collective bafflement from the community, TOC and End Users.

To be clear: I am 100% supportive of the CNCF using resources and
brand to kick projects, RFCs, RFPs, and who knows what.  But please do
it in the OPEN.  The CNCF should not compete with its membership.

[1]
https://www.linuxfoundation.org/press-release/2019/02/cncf-launches-cloud-native-network-functions-cnf-testbed/



On Thu, Mar 12, 2020 at 5:37 AM Chris Wright <chrisw@...> wrote:
>
> On Wed, Mar 11, 2020, 7:23 PM Liz Rice <liz@...> wrote:
>>
>> Lots to unpack here, Chris, and as it’s 11pm I may not do it full justice in this response but I did want to make a couple of quick points:
>>
>> First come, first served project assessment has been a worry for the TOC ever since I have been involved, if not longer. Accepting a project can be beneficial for that project but might be detrimental for a competing project. So, we try to look at competing / alternative solutions as part of any assessment. The order in which things are submitted is not the most important factor here.
>
>
> Agree with the sentiment here. I'd put it as domain squatting or cookie licking is not healthy for the broader industry.  What I find uncomfortable here is the potential added component of lack of transparency and awkward sense of conflict of interest when it appears to come from CNCF.
>
> Our stated goal is not to be a king maker. One natural outcome is projects with overlapping scope.
>
>> I think we all would have liked CNCF Hub to be made public some time ago.
>
>
> If someone other than CNCF said in private, "hey, we have a great project that nobody uses or has seen, so you should delay your process" I would expect the response to be pretty disinterested. "Thanks for your input, happy to evaluate after you exist."
>>
>> To be fair to Dan, there have been some other pressing concerns to deal with in this time; I still think the project could have been made public sooner, but we are where we are. The TOC was made aware of the project, and I hope you’d agree we should act with all the information we have at our disposal.  It was clear that CNCF Hub would likely have an impact on the CNCF’s overall strategy around artifact discovery and distribution (and the operator hub is clearly in that space).
>
> I guess I'm really struggling not to see reverse cookie licking...despite what's existed for some time (with highly relevant concerns discussed and laid to rest in an open, active SIG community), here's a new and unproven concept...seemingly from CNCF.  It does beg the question: What is CNCF's strategy for artifact discovery and distribution?
>>
>> Considering that strategy properly and calmly is in our view extremely important. We were aware that the delay was frustrating to the OF project and tried to at least give some explanation as to why there was hold-up (hence the comment in the PR that you refer to).
>
>
> Thank you for surfacing in a PR.
>
> The discussion is 13days after the SIG recommendation for acceptance, and draws out a suggestion the OF comply with a new, non-existent concept.
>
>> Over the past few months we have been working to make the project assessment process more scalable and transparent. But IMO process should never trump doing what we believe is the right thing for the community.
>
>
> I agree that process for process sake is the negative expression of beuraucracy.
>
> And I applaud all the work towards scalability and transparency. The task here is onerous and even thankless. So please take this as constructive feedback.
>
> It's why I suggested some clarity on guidelines. Because if we all decide independently on the right thing, we are not a community.
>
>
>>
>> Liz
>>
>> --
>> Liz Rice
>> @lizrice | lizrice.com | +44 (0) 780 126 1145
>> On 11 Mar 2020, 22:33 +0000, Chris Wright <chrisw@...>, wrote:
>>
>> During the evaluation of the Operator Framework for acceptance into
>> the CNCF as an incubation project, I was surprised to learn that the
>> vote was being held up by a request on behalf of a project yet to be
>> submitted to the TOC and SIGs for review. You can see the comment
>> here: https://github.com/cncf/toc/pull/303#issuecomment-594059717
>>
>> The project, CNCF Hub, was just submitted March 10th to the TOC
>> mailing list as a project intended to be used as the CNCF standard for
>> discovering and installing projects within this ecosystem. This
>> project was mentioned to the community at KubeCon San Diego, but no
>> significant community awareness until March 10th. The project is being
>> released as pre-beta helm based project. The potential appearance of a
>> fait accompli by having this conceptual prototype with a CNCF domain
>> name is one of my concerns, as it can easily give a misleading view of
>> community and CNCF support.
>>
>> As a foundation based on open source and open governance, I can't
>> accept a process that gives a CNCF sponsored project any special path
>> in or ability to hold up another project for consideration.
>>
>> Projects should never be reviewed according to fluid, inconsistent or
>> secretive guidelines.
>>
>> I recommend that we clarify the guidelines to ensure all projects are
>> treated equally and fairly.
>>
>> thanks,
>> -chris
>>
>>
>>
>>
>




Re: [EXTERNAL] Re: [cncf-toc] Point of process

Erin Boyd
 

To add to your thought, Brendan...I believe we should be thorough with our technical due diligence and understand what differentiates one project from another in the same space. And the CNCF, like any other company/organization is free to choose the best technology to address their problem space. 
However, I firmly believe that our job (TOC and TOC contributors) are to enable choices and diversity within the landscape. We don't want every project that goes into the cncf to operate exactly the same. There are advantages and disadvantages of both. It's not a one-size-fits-all. 
Ensuring we aren't being King Makers should be a fundamental value we hold in making these decisions.



On Thu, Mar 12, 2020, 11:40 AM Brendan Burns <bburns@...> wrote:
I'm in full agreement regarding transparency in the CNCF.

However, I think the discussion about OperatorHub has more to do with it's intersection with Helm and the Helm Hub as well as whether Operator Hub is built to enable alternate/federated hubs in the way that Helm is.

(there's lots of details on the other threads about OperatorHub)

So I don't think it is accurate to characterize the delay as being due to CNCF Hub, but rather the ToC wrangling with what makes sense around these kinds of artifact discovery mechanisms.

In the interests of not forking the discussion, if people want to discuss OperatorHub technical design let's use the other threads for that.

--brendan



From: cncf-toc@... <cncf-toc@...> on behalf of Erin Boyd via Lists.Cncf.Io <eboyd=redhat.com@...>
Sent: Thursday, March 12, 2020 7:39 AM
To: alexis richardson <alexis@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] Re: [cncf-toc] Point of process
 
Amen!

On Thu, Mar 12, 2020, 4:26 AM alexis richardson <alexis@...> wrote:
I believe the issue here is simple.  The CNCF is an open organisation
and should not develop its own projects in secret.  End of story.  We
saw this happen before eg "cloud native network functions" [1], which
led to collective bafflement from the community, TOC and End Users.

To be clear: I am 100% supportive of the CNCF using resources and
brand to kick projects, RFCs, RFPs, and who knows what.  But please do
it in the OPEN.  The CNCF should not compete with its membership.

[1]
https://www.linuxfoundation.org/press-release/2019/02/cncf-launches-cloud-native-network-functions-cnf-testbed/



On Thu, Mar 12, 2020 at 5:37 AM Chris Wright <chrisw@...> wrote:
>
> On Wed, Mar 11, 2020, 7:23 PM Liz Rice <liz@...> wrote:
>>
>> Lots to unpack here, Chris, and as it’s 11pm I may not do it full justice in this response but I did want to make a couple of quick points:
>>
>> First come, first served project assessment has been a worry for the TOC ever since I have been involved, if not longer. Accepting a project can be beneficial for that project but might be detrimental for a competing project. So, we try to look at competing / alternative solutions as part of any assessment. The order in which things are submitted is not the most important factor here.
>
>
> Agree with the sentiment here. I'd put it as domain squatting or cookie licking is not healthy for the broader industry.  What I find uncomfortable here is the potential added component of lack of transparency and awkward sense of conflict of interest when it appears to come from CNCF.
>
> Our stated goal is not to be a king maker. One natural outcome is projects with overlapping scope.
>
>> I think we all would have liked CNCF Hub to be made public some time ago.
>
>
> If someone other than CNCF said in private, "hey, we have a great project that nobody uses or has seen, so you should delay your process" I would expect the response to be pretty disinterested. "Thanks for your input, happy to evaluate after you exist."
>>
>> To be fair to Dan, there have been some other pressing concerns to deal with in this time; I still think the project could have been made public sooner, but we are where we are. The TOC was made aware of the project, and I hope you’d agree we should act with all the information we have at our disposal.  It was clear that CNCF Hub would likely have an impact on the CNCF’s overall strategy around artifact discovery and distribution (and the operator hub is clearly in that space).
>
> I guess I'm really struggling not to see reverse cookie licking...despite what's existed for some time (with highly relevant concerns discussed and laid to rest in an open, active SIG community), here's a new and unproven concept...seemingly from CNCF.  It does beg the question: What is CNCF's strategy for artifact discovery and distribution?
>>
>> Considering that strategy properly and calmly is in our view extremely important. We were aware that the delay was frustrating to the OF project and tried to at least give some explanation as to why there was hold-up (hence the comment in the PR that you refer to).
>
>
> Thank you for surfacing in a PR.
>
> The discussion is 13days after the SIG recommendation for acceptance, and draws out a suggestion the OF comply with a new, non-existent concept.
>
>> Over the past few months we have been working to make the project assessment process more scalable and transparent. But IMO process should never trump doing what we believe is the right thing for the community.
>
>
> I agree that process for process sake is the negative expression of beuraucracy.
>
> And I applaud all the work towards scalability and transparency. The task here is onerous and even thankless. So please take this as constructive feedback.
>
> It's why I suggested some clarity on guidelines. Because if we all decide independently on the right thing, we are not a community.
>
>
>>
>> Liz
>>
>> --
>> Liz Rice
>> @lizrice | lizrice.com | +44 (0) 780 126 1145
>> On 11 Mar 2020, 22:33 +0000, Chris Wright <chrisw@...>, wrote:
>>
>> During the evaluation of the Operator Framework for acceptance into
>> the CNCF as an incubation project, I was surprised to learn that the
>> vote was being held up by a request on behalf of a project yet to be
>> submitted to the TOC and SIGs for review. You can see the comment
>> here: https://github.com/cncf/toc/pull/303#issuecomment-594059717
>>
>> The project, CNCF Hub, was just submitted March 10th to the TOC
>> mailing list as a project intended to be used as the CNCF standard for
>> discovering and installing projects within this ecosystem. This
>> project was mentioned to the community at KubeCon San Diego, but no
>> significant community awareness until March 10th. The project is being
>> released as pre-beta helm based project. The potential appearance of a
>> fait accompli by having this conceptual prototype with a CNCF domain
>> name is one of my concerns, as it can easily give a misleading view of
>> community and CNCF support.
>>
>> As a foundation based on open source and open governance, I can't
>> accept a process that gives a CNCF sponsored project any special path
>> in or ability to hold up another project for consideration.
>>
>> Projects should never be reviewed according to fluid, inconsistent or
>> secretive guidelines.
>>
>> I recommend that we clarify the guidelines to ensure all projects are
>> treated equally and fairly.
>>
>> thanks,
>> -chris
>>
>>
>>
>>
>




Re: [EXTERNAL] Re: [cncf-toc] Point of process

Brendan Burns
 

I'm in full agreement regarding transparency in the CNCF.

However, I think the discussion about OperatorHub has more to do with it's intersection with Helm and the Helm Hub as well as whether Operator Hub is built to enable alternate/federated hubs in the way that Helm is.

(there's lots of details on the other threads about OperatorHub)

So I don't think it is accurate to characterize the delay as being due to CNCF Hub, but rather the ToC wrangling with what makes sense around these kinds of artifact discovery mechanisms.

In the interests of not forking the discussion, if people want to discuss OperatorHub technical design let's use the other threads for that.

--brendan



From: cncf-toc@... <cncf-toc@...> on behalf of Erin Boyd via Lists.Cncf.Io <eboyd=redhat.com@...>
Sent: Thursday, March 12, 2020 7:39 AM
To: alexis richardson <alexis@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: [EXTERNAL] Re: [cncf-toc] Point of process
 
Amen!

On Thu, Mar 12, 2020, 4:26 AM alexis richardson <alexis@...> wrote:
I believe the issue here is simple.  The CNCF is an open organisation
and should not develop its own projects in secret.  End of story.  We
saw this happen before eg "cloud native network functions" [1], which
led to collective bafflement from the community, TOC and End Users.

To be clear: I am 100% supportive of the CNCF using resources and
brand to kick projects, RFCs, RFPs, and who knows what.  But please do
it in the OPEN.  The CNCF should not compete with its membership.

[1]
https://www.linuxfoundation.org/press-release/2019/02/cncf-launches-cloud-native-network-functions-cnf-testbed/



On Thu, Mar 12, 2020 at 5:37 AM Chris Wright <chrisw@...> wrote:
>
> On Wed, Mar 11, 2020, 7:23 PM Liz Rice <liz@...> wrote:
>>
>> Lots to unpack here, Chris, and as it’s 11pm I may not do it full justice in this response but I did want to make a couple of quick points:
>>
>> First come, first served project assessment has been a worry for the TOC ever since I have been involved, if not longer. Accepting a project can be beneficial for that project but might be detrimental for a competing project. So, we try to look at competing / alternative solutions as part of any assessment. The order in which things are submitted is not the most important factor here.
>
>
> Agree with the sentiment here. I'd put it as domain squatting or cookie licking is not healthy for the broader industry.  What I find uncomfortable here is the potential added component of lack of transparency and awkward sense of conflict of interest when it appears to come from CNCF.
>
> Our stated goal is not to be a king maker. One natural outcome is projects with overlapping scope.
>
>> I think we all would have liked CNCF Hub to be made public some time ago.
>
>
> If someone other than CNCF said in private, "hey, we have a great project that nobody uses or has seen, so you should delay your process" I would expect the response to be pretty disinterested. "Thanks for your input, happy to evaluate after you exist."
>>
>> To be fair to Dan, there have been some other pressing concerns to deal with in this time; I still think the project could have been made public sooner, but we are where we are. The TOC was made aware of the project, and I hope you’d agree we should act with all the information we have at our disposal.  It was clear that CNCF Hub would likely have an impact on the CNCF’s overall strategy around artifact discovery and distribution (and the operator hub is clearly in that space).
>
> I guess I'm really struggling not to see reverse cookie licking...despite what's existed for some time (with highly relevant concerns discussed and laid to rest in an open, active SIG community), here's a new and unproven concept...seemingly from CNCF.  It does beg the question: What is CNCF's strategy for artifact discovery and distribution?
>>
>> Considering that strategy properly and calmly is in our view extremely important. We were aware that the delay was frustrating to the OF project and tried to at least give some explanation as to why there was hold-up (hence the comment in the PR that you refer to).
>
>
> Thank you for surfacing in a PR.
>
> The discussion is 13days after the SIG recommendation for acceptance, and draws out a suggestion the OF comply with a new, non-existent concept.
>
>> Over the past few months we have been working to make the project assessment process more scalable and transparent. But IMO process should never trump doing what we believe is the right thing for the community.
>
>
> I agree that process for process sake is the negative expression of beuraucracy.
>
> And I applaud all the work towards scalability and transparency. The task here is onerous and even thankless. So please take this as constructive feedback.
>
> It's why I suggested some clarity on guidelines. Because if we all decide independently on the right thing, we are not a community.
>
>
>>
>> Liz
>>
>> --
>> Liz Rice
>> @lizrice | lizrice.com | +44 (0) 780 126 1145
>> On 11 Mar 2020, 22:33 +0000, Chris Wright <chrisw@...>, wrote:
>>
>> During the evaluation of the Operator Framework for acceptance into
>> the CNCF as an incubation project, I was surprised to learn that the
>> vote was being held up by a request on behalf of a project yet to be
>> submitted to the TOC and SIGs for review. You can see the comment
>> here: https://github.com/cncf/toc/pull/303#issuecomment-594059717
>>
>> The project, CNCF Hub, was just submitted March 10th to the TOC
>> mailing list as a project intended to be used as the CNCF standard for
>> discovering and installing projects within this ecosystem. This
>> project was mentioned to the community at KubeCon San Diego, but no
>> significant community awareness until March 10th. The project is being
>> released as pre-beta helm based project. The potential appearance of a
>> fait accompli by having this conceptual prototype with a CNCF domain
>> name is one of my concerns, as it can easily give a misleading view of
>> community and CNCF support.
>>
>> As a foundation based on open source and open governance, I can't
>> accept a process that gives a CNCF sponsored project any special path
>> in or ability to hold up another project for consideration.
>>
>> Projects should never be reviewed according to fluid, inconsistent or
>> secretive guidelines.
>>
>> I recommend that we clarify the guidelines to ensure all projects are
>> treated equally and fairly.
>>
>> thanks,
>> -chris
>>
>>
>>
>>
>




Re: Point of process

Alex Chircop
 


While I recognize the importance and the impact of an initiative like hub.cncf.io to the cloud native mission, I also agree that this should be discussed and introduced in a more open manner.

The initiative is important for a number of reasons, including but not limited to:
1) A "package manager" that provides a simple, central way to source software for a platform is key to critical mass adoption of a platform - historically just think of the impact that package management had on the adoption of the various Linux distributions.
2) Software and package management is also a key step to ISV support for a platform - and that too is key to the acceptance and adoption of the platform

That said, it is critical to get this right, so openness, where we can benefit from some of the already mature initiatives in the community (even if they are competing) is the right thing:
1) When it comes to installing software, end-users want something that "just works" - so making it easy for software devs and orgs that release software to adopt the platform, test and manage distributions
2) Software deployments often have dependencies which may/should be managed through the overall solution - it does not make for a good user experience if different components of a package have different ways of sourcing or deploying - this is why it is key to get this right, and get systems to work together - even if this means that we may need to be opinionated, and even if it means that this requires resources to properly curate the repository
3) Cloud Native software deployment often have additional complexity or considerations during "day 2" operations - such as dealing with upgrades (and the dependency paths) and scaling etc ... - which is why it is odd (based on this email thread and yesterday's discussion) that the Operator Framework (and others) appear not to be involved in the initiative as this is something that this project has focused on
4) We should also consider a plan for how this hub is curated and managed - if end-users try the solution and the quality is not high (e.g. today there are already multiple options to install a give software package listed in hub) then they will move on, and we will not get many attempts to win them back over

TL;DR
An initiative like hub is key to the adoption of cloud native technologies and should be a central initiative for the CNCF and it's mission.   It is also too important to get it wrong and squander good will of end-users - when the core brand of the CNCF is placed on an initiative that is not successful, and/or does not gain traction, it dilutes the benefit and credibility of the whole community.

Kind Regards,
Alex


From: cncf-toc@... <cncf-toc@...> on behalf of Chris Wright via Lists.Cncf.Io <chrisw=redhat.com@...>
Sent: 12 March 2020 12:33
To: Alexis Richardson <alexis@...>
Cc: cncf-toc@... <cncf-toc@...>
Subject: Re: [cncf-toc] Point of process
 
Yes, I completely agree

On Thu, Mar 12, 2020, 6:26 AM Alexis Richardson <alexis@...> wrote:
I believe the issue here is simple.  The CNCF is an open organisation
and should not develop its own projects in secret.  End of story.  We
saw this happen before eg "cloud native network functions" [1], which
led to collective bafflement from the community, TOC and End Users.

To be clear: I am 100% supportive of the CNCF using resources and
brand to kick projects, RFCs, RFPs, and who knows what.  But please do
it in the OPEN.  The CNCF should not compete with its membership.

[1]
https://www.linuxfoundation.org/press-release/2019/02/cncf-launches-cloud-native-network-functions-cnf-testbed/



On Thu, Mar 12, 2020 at 5:37 AM Chris Wright <chrisw@...> wrote:
>
> On Wed, Mar 11, 2020, 7:23 PM Liz Rice <liz@...> wrote:
>>
>> Lots to unpack here, Chris, and as it’s 11pm I may not do it full justice in this response but I did want to make a couple of quick points:
>>
>> First come, first served project assessment has been a worry for the TOC ever since I have been involved, if not longer. Accepting a project can be beneficial for that project but might be detrimental for a competing project. So, we try to look at competing / alternative solutions as part of any assessment. The order in which things are submitted is not the most important factor here.
>
>
> Agree with the sentiment here. I'd put it as domain squatting or cookie licking is not healthy for the broader industry.  What I find uncomfortable here is the potential added component of lack of transparency and awkward sense of conflict of interest when it appears to come from CNCF.
>
> Our stated goal is not to be a king maker. One natural outcome is projects with overlapping scope.
>
>> I think we all would have liked CNCF Hub to be made public some time ago.
>
>
> If someone other than CNCF said in private, "hey, we have a great project that nobody uses or has seen, so you should delay your process" I would expect the response to be pretty disinterested. "Thanks for your input, happy to evaluate after you exist."
>>
>> To be fair to Dan, there have been some other pressing concerns to deal with in this time; I still think the project could have been made public sooner, but we are where we are. The TOC was made aware of the project, and I hope you’d agree we should act with all the information we have at our disposal.  It was clear that CNCF Hub would likely have an impact on the CNCF’s overall strategy around artifact discovery and distribution (and the operator hub is clearly in that space).
>
> I guess I'm really struggling not to see reverse cookie licking...despite what's existed for some time (with highly relevant concerns discussed and laid to rest in an open, active SIG community), here's a new and unproven concept...seemingly from CNCF.  It does beg the question: What is CNCF's strategy for artifact discovery and distribution?
>>
>> Considering that strategy properly and calmly is in our view extremely important. We were aware that the delay was frustrating to the OF project and tried to at least give some explanation as to why there was hold-up (hence the comment in the PR that you refer to).
>
>
> Thank you for surfacing in a PR.
>
> The discussion is 13days after the SIG recommendation for acceptance, and draws out a suggestion the OF comply with a new, non-existent concept.
>
>> Over the past few months we have been working to make the project assessment process more scalable and transparent. But IMO process should never trump doing what we believe is the right thing for the community.
>
>
> I agree that process for process sake is the negative expression of beuraucracy.
>
> And I applaud all the work towards scalability and transparency. The task here is onerous and even thankless. So please take this as constructive feedback.
>
> It's why I suggested some clarity on guidelines. Because if we all decide independently on the right thing, we are not a community.
>
>
>>
>> Liz
>>
>> --
>> Liz Rice
>> @lizrice | lizrice.com | +44 (0) 780 126 1145
>> On 11 Mar 2020, 22:33 +0000, Chris Wright <chrisw@...>, wrote:
>>
>> During the evaluation of the Operator Framework for acceptance into
>> the CNCF as an incubation project, I was surprised to learn that the
>> vote was being held up by a request on behalf of a project yet to be
>> submitted to the TOC and SIGs for review. You can see the comment
>> here: https://github.com/cncf/toc/pull/303#issuecomment-594059717
>>
>> The project, CNCF Hub, was just submitted March 10th to the TOC
>> mailing list as a project intended to be used as the CNCF standard for
>> discovering and installing projects within this ecosystem. This
>> project was mentioned to the community at KubeCon San Diego, but no
>> significant community awareness until March 10th. The project is being
>> released as pre-beta helm based project. The potential appearance of a
>> fait accompli by having this conceptual prototype with a CNCF domain
>> name is one of my concerns, as it can easily give a misleading view of
>> community and CNCF support.
>>
>> As a foundation based on open source and open governance, I can't
>> accept a process that gives a CNCF sponsored project any special path
>> in or ability to hold up another project for consideration.
>>
>> Projects should never be reviewed according to fluid, inconsistent or
>> secretive guidelines.
>>
>> I recommend that we clarify the guidelines to ensure all projects are
>> treated equally and fairly.
>>
>> thanks,
>> -chris
>>
>>
>>
>>


Re: Point of process

Erin Boyd
 

Amen!


On Thu, Mar 12, 2020, 4:26 AM alexis richardson <alexis@...> wrote:
I believe the issue here is simple.  The CNCF is an open organisation
and should not develop its own projects in secret.  End of story.  We
saw this happen before eg "cloud native network functions" [1], which
led to collective bafflement from the community, TOC and End Users.

To be clear: I am 100% supportive of the CNCF using resources and
brand to kick projects, RFCs, RFPs, and who knows what.  But please do
it in the OPEN.  The CNCF should not compete with its membership.

[1]
https://www.linuxfoundation.org/press-release/2019/02/cncf-launches-cloud-native-network-functions-cnf-testbed/



On Thu, Mar 12, 2020 at 5:37 AM Chris Wright <chrisw@...> wrote:
>
> On Wed, Mar 11, 2020, 7:23 PM Liz Rice <liz@...> wrote:
>>
>> Lots to unpack here, Chris, and as it’s 11pm I may not do it full justice in this response but I did want to make a couple of quick points:
>>
>> First come, first served project assessment has been a worry for the TOC ever since I have been involved, if not longer. Accepting a project can be beneficial for that project but might be detrimental for a competing project. So, we try to look at competing / alternative solutions as part of any assessment. The order in which things are submitted is not the most important factor here.
>
>
> Agree with the sentiment here. I'd put it as domain squatting or cookie licking is not healthy for the broader industry.  What I find uncomfortable here is the potential added component of lack of transparency and awkward sense of conflict of interest when it appears to come from CNCF.
>
> Our stated goal is not to be a king maker. One natural outcome is projects with overlapping scope.
>
>> I think we all would have liked CNCF Hub to be made public some time ago.
>
>
> If someone other than CNCF said in private, "hey, we have a great project that nobody uses or has seen, so you should delay your process" I would expect the response to be pretty disinterested. "Thanks for your input, happy to evaluate after you exist."
>>
>> To be fair to Dan, there have been some other pressing concerns to deal with in this time; I still think the project could have been made public sooner, but we are where we are. The TOC was made aware of the project, and I hope you’d agree we should act with all the information we have at our disposal.  It was clear that CNCF Hub would likely have an impact on the CNCF’s overall strategy around artifact discovery and distribution (and the operator hub is clearly in that space).
>
> I guess I'm really struggling not to see reverse cookie licking...despite what's existed for some time (with highly relevant concerns discussed and laid to rest in an open, active SIG community), here's a new and unproven concept...seemingly from CNCF.  It does beg the question: What is CNCF's strategy for artifact discovery and distribution?
>>
>> Considering that strategy properly and calmly is in our view extremely important. We were aware that the delay was frustrating to the OF project and tried to at least give some explanation as to why there was hold-up (hence the comment in the PR that you refer to).
>
>
> Thank you for surfacing in a PR.
>
> The discussion is 13days after the SIG recommendation for acceptance, and draws out a suggestion the OF comply with a new, non-existent concept.
>
>> Over the past few months we have been working to make the project assessment process more scalable and transparent. But IMO process should never trump doing what we believe is the right thing for the community.
>
>
> I agree that process for process sake is the negative expression of beuraucracy.
>
> And I applaud all the work towards scalability and transparency. The task here is onerous and even thankless. So please take this as constructive feedback.
>
> It's why I suggested some clarity on guidelines. Because if we all decide independently on the right thing, we are not a community.
>
>
>>
>> Liz
>>
>> --
>> Liz Rice
>> @lizrice | lizrice.com | +44 (0) 780 126 1145
>> On 11 Mar 2020, 22:33 +0000, Chris Wright <chrisw@...>, wrote:
>>
>> During the evaluation of the Operator Framework for acceptance into
>> the CNCF as an incubation project, I was surprised to learn that the
>> vote was being held up by a request on behalf of a project yet to be
>> submitted to the TOC and SIGs for review. You can see the comment
>> here: https://github.com/cncf/toc/pull/303#issuecomment-594059717
>>
>> The project, CNCF Hub, was just submitted March 10th to the TOC
>> mailing list as a project intended to be used as the CNCF standard for
>> discovering and installing projects within this ecosystem. This
>> project was mentioned to the community at KubeCon San Diego, but no
>> significant community awareness until March 10th. The project is being
>> released as pre-beta helm based project. The potential appearance of a
>> fait accompli by having this conceptual prototype with a CNCF domain
>> name is one of my concerns, as it can easily give a misleading view of
>> community and CNCF support.
>>
>> As a foundation based on open source and open governance, I can't
>> accept a process that gives a CNCF sponsored project any special path
>> in or ability to hold up another project for consideration.
>>
>> Projects should never be reviewed according to fluid, inconsistent or
>> secretive guidelines.
>>
>> I recommend that we clarify the guidelines to ensure all projects are
>> treated equally and fairly.
>>
>> thanks,
>> -chris
>>
>>
>>
>>
>




Re: Point of process

Chris Wright
 

Yes, I completely agree

On Thu, Mar 12, 2020, 6:26 AM Alexis Richardson <alexis@...> wrote:
I believe the issue here is simple.  The CNCF is an open organisation
and should not develop its own projects in secret.  End of story.  We
saw this happen before eg "cloud native network functions" [1], which
led to collective bafflement from the community, TOC and End Users.

To be clear: I am 100% supportive of the CNCF using resources and
brand to kick projects, RFCs, RFPs, and who knows what.  But please do
it in the OPEN.  The CNCF should not compete with its membership.

[1]
https://www.linuxfoundation.org/press-release/2019/02/cncf-launches-cloud-native-network-functions-cnf-testbed/



On Thu, Mar 12, 2020 at 5:37 AM Chris Wright <chrisw@...> wrote:
>
> On Wed, Mar 11, 2020, 7:23 PM Liz Rice <liz@...> wrote:
>>
>> Lots to unpack here, Chris, and as it’s 11pm I may not do it full justice in this response but I did want to make a couple of quick points:
>>
>> First come, first served project assessment has been a worry for the TOC ever since I have been involved, if not longer. Accepting a project can be beneficial for that project but might be detrimental for a competing project. So, we try to look at competing / alternative solutions as part of any assessment. The order in which things are submitted is not the most important factor here.
>
>
> Agree with the sentiment here. I'd put it as domain squatting or cookie licking is not healthy for the broader industry.  What I find uncomfortable here is the potential added component of lack of transparency and awkward sense of conflict of interest when it appears to come from CNCF.
>
> Our stated goal is not to be a king maker. One natural outcome is projects with overlapping scope.
>
>> I think we all would have liked CNCF Hub to be made public some time ago.
>
>
> If someone other than CNCF said in private, "hey, we have a great project that nobody uses or has seen, so you should delay your process" I would expect the response to be pretty disinterested. "Thanks for your input, happy to evaluate after you exist."
>>
>> To be fair to Dan, there have been some other pressing concerns to deal with in this time; I still think the project could have been made public sooner, but we are where we are. The TOC was made aware of the project, and I hope you’d agree we should act with all the information we have at our disposal.  It was clear that CNCF Hub would likely have an impact on the CNCF’s overall strategy around artifact discovery and distribution (and the operator hub is clearly in that space).
>
> I guess I'm really struggling not to see reverse cookie licking...despite what's existed for some time (with highly relevant concerns discussed and laid to rest in an open, active SIG community), here's a new and unproven concept...seemingly from CNCF.  It does beg the question: What is CNCF's strategy for artifact discovery and distribution?
>>
>> Considering that strategy properly and calmly is in our view extremely important. We were aware that the delay was frustrating to the OF project and tried to at least give some explanation as to why there was hold-up (hence the comment in the PR that you refer to).
>
>
> Thank you for surfacing in a PR.
>
> The discussion is 13days after the SIG recommendation for acceptance, and draws out a suggestion the OF comply with a new, non-existent concept.
>
>> Over the past few months we have been working to make the project assessment process more scalable and transparent. But IMO process should never trump doing what we believe is the right thing for the community.
>
>
> I agree that process for process sake is the negative expression of beuraucracy.
>
> And I applaud all the work towards scalability and transparency. The task here is onerous and even thankless. So please take this as constructive feedback.
>
> It's why I suggested some clarity on guidelines. Because if we all decide independently on the right thing, we are not a community.
>
>
>>
>> Liz
>>
>> --
>> Liz Rice
>> @lizrice | lizrice.com | +44 (0) 780 126 1145
>> On 11 Mar 2020, 22:33 +0000, Chris Wright <chrisw@...>, wrote:
>>
>> During the evaluation of the Operator Framework for acceptance into
>> the CNCF as an incubation project, I was surprised to learn that the
>> vote was being held up by a request on behalf of a project yet to be
>> submitted to the TOC and SIGs for review. You can see the comment
>> here: https://github.com/cncf/toc/pull/303#issuecomment-594059717
>>
>> The project, CNCF Hub, was just submitted March 10th to the TOC
>> mailing list as a project intended to be used as the CNCF standard for
>> discovering and installing projects within this ecosystem. This
>> project was mentioned to the community at KubeCon San Diego, but no
>> significant community awareness until March 10th. The project is being
>> released as pre-beta helm based project. The potential appearance of a
>> fait accompli by having this conceptual prototype with a CNCF domain
>> name is one of my concerns, as it can easily give a misleading view of
>> community and CNCF support.
>>
>> As a foundation based on open source and open governance, I can't
>> accept a process that gives a CNCF sponsored project any special path
>> in or ability to hold up another project for consideration.
>>
>> Projects should never be reviewed according to fluid, inconsistent or
>> secretive guidelines.
>>
>> I recommend that we clarify the guidelines to ensure all projects are
>> treated equally and fairly.
>>
>> thanks,
>> -chris
>>
>>
>>
>>

3001 - 3020 of 7342